4 ms·

> In another language you'd risk having a pointer to invalid memory when the function returns if the pointer escapes the function, and so it is advised to use p

> In another language you'd risk having a pointer to invalid memory when the function returns if the pointer escapes the function, and so it is advised to use pointers to objects on the stack sparingly if at all. Just a nitpick, this is only true for non-garbage-collected (or refcounted) languages. :-)

lmkg 7y ago
Well, if you're gonna nitpick... A garbage-collected language wouldn't let you allocate such items on the stack in the first place. GC languages tend not to let you choose where to allocate in the first place, and have obligatory heap semantics for reference types. Some compilers (including Go and Java, to my knowledge) will attempt to optimize the implementation to stack allocation when possible using escape analysis, but this is less precise, and more opaque, then Rust's allocation. And you won't get feedback if it stops working. So, by GP's comment of "unheard of (or just plain dangerous)", the "unheard-of" applies to GC languages and "plain dangerous" would apply non-GC languages.
- pjmlp 7y ago
  Here goes a list from GC enabled languages that let you chose where to allocate. Modula-3, Oberon, Oberon-2, Active Oberon, Mesa/Cedar, Component Pascal, Eiffel, Sing#, System C#, C#, Swift, D, Nim
  - ncmncm 7y ago
    I prefer the term "obligate-GC languages": you don't get to choose whether GC runs. Otherwise, Rust and C++ count as "GC-enabled", and comparisons are vacuous. Reference-counting, a form of GC very commonly used in Rust and C++, is inefficient compared to more intrusive schemes, particularly where there may be contention for the count, but may be applied selectively, e.g. never on critical paths, so that the inefficiency has zero impact on overall system performance. Obligate-GC advocates like to point at custom benchmarks showing overhead at a small percentage. They are invariably lying, by reporting only the time that the profiler says the program counter is pointing to GC code, and hiding the much-larger results of loss of cache locality on the system as a whole. Typically they don't even know they are lying, which should not give one much confidence in their engineering judgment.
    - pjmlp 7y ago
      You mean custom benchmarks like Midori powering Bing for Asian requests, the ixy paper, Android GPGPU debugger, Fuchsia TCP/IP stack, ChromeOS and Google Cloud sandboxes. Yep, really lying.
      - nickpsecurity 7y ago
        The pre-Cortana version of the speech service ran on Midori, too, with safer code: https://www.reddit.com/r/programming/comments/3t50xg/more_information_about_microsofts_oncesecret/ https://www.reddit.com/r/programming/comments/3t50xg/more_in... They admit it wasn't quite full-GC stuff. It was close to the C++. It did use the language safety and parallelism to its advantage on top of the Midori OS. They ended up improving performance over the original. Still worth mentioning even if not fully-GC. I mean, they could've always used a real-time GC if that was important. There's already commercial and academic ones. For some reason, these projects never try to do that. I think even those developing GC'd systems might not know about RT designs.
- zeroxfe 7y ago
  > Well, if you're gonna nitpick... :-) > A garbage-collected language wouldn't let you allocate such items on the stack in the first place. I get your point, but I don't think this is entirely true. When people think of call stacks in the general sense, there's a major distinction between CPU stacks and managed stacks. For example in both Java and Go, stack allocations are determined at compile time, and heap allocations at runtime. (Obv, stacks here are not actual CPU stacks, just managed memory stacks depending on the implementation.)
fluffything 7y ago
Which garbage-collected languages put automatic variables in an actual stack that gets bumped on function calls even when you pass pointers to the automatic variables ?
Gaelan 7y ago
In garbage collected languages, are there any objects on the stack? I’m not familiar with GC implementations, but at least theoretically everything is allocated on the heap. Maybe some implementations keep things on the stack as an optimization?
- jhomedall 7y ago
  Escape analysis is a common optimization for GCed languages. e: Also, many languages allow the user create user-defined value types, which are copied rather than referenced. Variables containing these can be stack-allocated.
- pjmlp 7y ago
  Yes, see my reply to other thread. https://news.ycombinator.com/item?id=21335506 https://news.ycombinator.com/item?id=21335506
dnet 7y ago
You omitted an important part: the pointer pointing to the stack. In GC'd or refcounted languages, (almost) everything is on the heap (occasional exceptions being primitive types like integers). This of course leads to worse performance because of an additional dereferencing step and cache misses.

lmkg 7y ago

Well, if you're gonna nitpick... A garbage-collected language wouldn't let you allocate such items on the stack in the first place. GC languages tend not to let you choose where to allocate in the first place, and have obligatory heap semantics for reference types. Some compilers (including Go and Java, to my knowledge) will attempt to optimize the implementation to stack allocation when possible using escape analysis, but this is less precise, and more opaque, then Rust's allocation. And you won't get feedback if it stops working. So, by GP's comment of "unheard of (or just plain dangerous)", the "unheard-of" applies to GC languages and "plain dangerous" would apply non-GC languages.

pjmlp 7y ago
Here goes a list from GC enabled languages that let you chose where to allocate. Modula-3, Oberon, Oberon-2, Active Oberon, Mesa/Cedar, Component Pascal, Eiffel, Sing#, System C#, C#, Swift, D, Nim
- ncmncm 7y ago
  I prefer the term "obligate-GC languages": you don't get to choose whether GC runs. Otherwise, Rust and C++ count as "GC-enabled", and comparisons are vacuous. Reference-counting, a form of GC very commonly used in Rust and C++, is inefficient compared to more intrusive schemes, particularly where there may be contention for the count, but may be applied selectively, e.g. never on critical paths, so that the inefficiency has zero impact on overall system performance. Obligate-GC advocates like to point at custom benchmarks showing overhead at a small percentage. They are invariably lying, by reporting only the time that the profiler says the program counter is pointing to GC code, and hiding the much-larger results of loss of cache locality on the system as a whole. Typically they don't even know they are lying, which should not give one much confidence in their engineering judgment.
  - pjmlp 7y ago
    You mean custom benchmarks like Midori powering Bing for Asian requests, the ixy paper, Android GPGPU debugger, Fuchsia TCP/IP stack, ChromeOS and Google Cloud sandboxes. Yep, really lying.
    - nickpsecurity 7y ago
      The pre-Cortana version of the speech service ran on Midori, too, with safer code: https://www.reddit.com/r/programming/comments/3t50xg/more_information_about_microsofts_oncesecret/ https://www.reddit.com/r/programming/comments/3t50xg/more_in... They admit it wasn't quite full-GC stuff. It was close to the C++. It did use the language safety and parallelism to its advantage on top of the Midori OS. They ended up improving performance over the original. Still worth mentioning even if not fully-GC. I mean, they could've always used a real-time GC if that was important. There's already commercial and academic ones. For some reason, these projects never try to do that. I think even those developing GC'd systems might not know about RT designs.
zeroxfe 7y ago
> Well, if you're gonna nitpick... :-) > A garbage-collected language wouldn't let you allocate such items on the stack in the first place. I get your point, but I don't think this is entirely true. When people think of call stacks in the general sense, there's a major distinction between CPU stacks and managed stacks. For example in both Java and Go, stack allocations are determined at compile time, and heap allocations at runtime. (Obv, stacks here are not actual CPU stacks, just managed memory stacks depending on the implementation.)

fluffything 7y ago

Which garbage-collected languages put automatic variables in an actual stack that gets bumped on function calls even when you pass pointers to the automatic variables ?

Gaelan 7y ago

In garbage collected languages, are there any objects on the stack? I’m not familiar with GC implementations, but at least theoretically everything is allocated on the heap. Maybe some implementations keep things on the stack as an optimization?

jhomedall 7y ago
Escape analysis is a common optimization for GCed languages. e: Also, many languages allow the user create user-defined value types, which are copied rather than referenced. Variables containing these can be stack-allocated.
pjmlp 7y ago
Yes, see my reply to other thread. https://news.ycombinator.com/item?id=21335506 https://news.ycombinator.com/item?id=21335506

dnet 7y ago

You omitted an important part: the pointer pointing to the stack. In GC'd or refcounted languages, (almost) everything is on the heap (occasional exceptions being primitive types like integers). This of course leads to worse performance because of an additional dereferencing step and cache misses.