3 ms·

> Not explicit programmer control, but I think you can reasonably make it do what you want. Escape analysis, like any such analysis, gets much more difficult i

> Not explicit programmer control, but I think you can reasonably make it do what you want. Escape analysis, like any such analysis, gets much more difficult in the presence of higher-order control flow. Currently the Go compilers punt on higher order control flow analysis. And Go uses higher-order control flow in spades, due to its heavy reliance on interfaces. The end result is that lots of stuff is heap allocated. > Java where everything is a pointer and gets spread out all over memory. That's not true for Java. Its generational garbage collector performs bump allocation in the nursery, yielding tightly packed objects with excellent cache behavior. Allocation in HotSpot is like 3-5 instructions (really!) I think the HotSpot approach makes the most sense: instead of trying to carve out special cases that fall down regularly, focus on making heap allocations fast, as you'll need to make them fast anyway. After that, add things like escape analysis (which HotSpot has as well).

geodel 10y ago
> That's not true for Java. Its generational garbage collector performs bump allocation in the nursery, yielding tightly packed objects with excellent cache behavior. Allocation in HotSpot is like 3-5 instructions (really!) When I see this link I get different impression. http://mechanical-sympathy.blogspot.com/2012/10/compact-off-heap-structurestuples-in.html http://mechanical-sympathy.blogspot.com/2012/10/compact-off-... It is only heavy use of sun.misc.Unsafe and unidiomatic coding style that give Java semblance of memory efficiency.
- pcwalton 10y ago
  That post's numbers are entirely based a giant multi-gigabyte long-lived array: the classic worst case for a generational GC. That is not representative of most memory allocations. The generational hypothesis, which has been empirically verified in real world code again and again, is that most allocations are short-lived and small.
  - geodel 10y ago
    There were 3 points mentioned in post with only 1 about GC. Performance and memory efficiency were major points not delivered by standard idiomatic Java code. Considering the popularity of memory compact Java collections like Fastutils etc I feel that memory bloat of standard Java is very common issue plaguing Java applications.
    - pcwalton 10y ago
      If you read the comments, you'll find that the issue is in fact GC: specifically, the cost of tenuring objects.
dilap 10y ago
Java: But you're still chasing pointers for an array of objects right? Vs being able to just say, "I want this array to be X objects, all laid out in in a row in memory." I'm not a java programmer, but I'm pretty sure I've seen code that used primitive types rather than classes to get around this. Actually, even Go isn't helping as much as it could here -- sometimes you want to have an array of objects that lays out each column (field) of memory contiguously, which Go gives you no easy way to do. But then neither does C or C++. Isn't allocation just a couple instructions for basically GC languages?
- pcwalton 10y ago
  > Isn't allocation just a couple instructions for basically GC languages? If those GC'd languages have a precise generational GC with bump allocation in the nursery. Go doesn't (and the proposed GC design doesn't allow for this, unfortunately).

geodel 10y ago

> That's not true for Java. Its generational garbage collector performs bump allocation in the nursery, yielding tightly packed objects with excellent cache behavior. Allocation in HotSpot is like 3-5 instructions (really!) When I see this link I get different impression. http://mechanical-sympathy.blogspot.com/2012/10/compact-off-heap-structurestuples-in.html http://mechanical-sympathy.blogspot.com/2012/10/compact-off-... It is only heavy use of sun.misc.Unsafe and unidiomatic coding style that give Java semblance of memory efficiency.

pcwalton 10y ago
That post's numbers are entirely based a giant multi-gigabyte long-lived array: the classic worst case for a generational GC. That is not representative of most memory allocations. The generational hypothesis, which has been empirically verified in real world code again and again, is that most allocations are short-lived and small.
- geodel 10y ago
  There were 3 points mentioned in post with only 1 about GC. Performance and memory efficiency were major points not delivered by standard idiomatic Java code. Considering the popularity of memory compact Java collections like Fastutils etc I feel that memory bloat of standard Java is very common issue plaguing Java applications.
  - pcwalton 10y ago
    If you read the comments, you'll find that the issue is in fact GC: specifically, the cost of tenuring objects.

dilap 10y ago

Java: But you're still chasing pointers for an array of objects right? Vs being able to just say, "I want this array to be X objects, all laid out in in a row in memory." I'm not a java programmer, but I'm pretty sure I've seen code that used primitive types rather than classes to get around this. Actually, even Go isn't helping as much as it could here -- sometimes you want to have an array of objects that lays out each column (field) of memory contiguously, which Go gives you no easy way to do. But then neither does C or C++. Isn't allocation just a couple instructions for basically GC languages?

pcwalton 10y ago
> Isn't allocation just a couple instructions for basically GC languages? If those GC'd languages have a precise generational GC with bump allocation in the nursery. Go doesn't (and the proposed GC design doesn't allow for this, unfortunately).