The HotSpot JVM stack allocates (actually, even better: it SROAs) in very similar conditions to when Go does: when escape analysis decides that a value does not escape. Even if it doesn't stack allocate, bump allocation in the nursery ends up being about as fast as stack allocation (which is, as far as I know, why HotSpot chose only to lock elide and not to stack allocate when they implemented escape analysis).
I haven't looked into the JVM's stack allocation logic in several years, so it may have improved to the point where that is now true. (It wasn't so in 2010.) However, Go does have features that make it easier to control allocations than Java. One example,
type s struct {
x int32
y int32
}
v := make([]s, 1e5)
The object v uses 1e5 * 8 bytes of storage. Equivalent Java code would require boxing of each s value. That is, instead of []s, you end up with []*s and allocating each s.
I wrote a blog post that showed how powerful JVM compilers like the new Graal can be with removing allocations. I can show a test case in Ruby running on Graal where there are many complicated objects that cross many method boundaries, and they're all entirely removed.
Graal can do normal escape analysis, and so scalar replacements, but it can also do partial escape analysis - that is doing scalar replacement even if an object will later escape.
I don't believe that. Yes, the bump allocation step is just as fast as stack allocation because you just increment a pointer. But the extra allocation triggers more frequent collections of the nursery which is much slower than decrementing the stack pointer which is how you "free" objects on the stack. Intuitively nursery allocation just can't be as stack allocation but I haven't seen any benchmarks.
Yes, it's true in general that stack allocation can be faster than even bump allocation in the nursery. But I wouldn't be surprised if the reason HotSpot doesn't bother is that doing SROA, post-inlining, covers enough cases in practice that doing interprocedural escape analysis in order to do stack allocation for a few more objects doesn't help much.
