Java does escape analysis, but if I remember correctly, it is no longer used for stack allocation (it is used for other advanced stuff, like lock elision, and replacing objects with scalars) because the JVM GCs have gotten so good that stack allocation provided no significant benefit. The reason is that stack allocation is relevant only for short-lived objects anyway, and for generational GCs, short-lived objects are (almost) a non-issue. GCs struggle much more with long-lived objects, which eventually require compaction, whose cost rises linearly with the size of the live data set. This is the cause of the problems with large heaps mentioned in the comments below.

Very interesting. Thank you for the update. I'm more than a few years out of date. I may have to place new bets. :)

FWIW, Azul has presented to our local user group (seajug.org) a few times, most recently Nov 2012. There's video http://www.nimret.org/seajug/index.jsp?p=2012%2Fnov%2F By all accounts, their allocation and garbage collection implementations are the best available.

> The runtime can figure out heap vs stack. Progressively better over time. Definitely better than I can do.

Not really true: when you get into higher order control flow it's a huge mess and usually escape analysis falls down. The Rust lifetime system allows stack allocation to a greater extent than any escape analysis system I know of.

That said, we've thought about doing escape analysis, but usually you don't need it in Rust: people reach for the garbage collector only when it's absolutely needed anyway, so having the compiler promote GC allocations to stack allocations automatically would only help in a tiny fraction of cases.

I would place my bets on that. The analysis is hard and the gain is quite small.

Dont take my word for it, they guys from Azul threw it out of the code completly and replaced it with something they call 'escape detection'.

“What is Azul’s support for Stack Allocation?”

Azul’s support for stack allocation is really support for Escape Detection – fast detection on when an object is escaping a stack lifetime. Sun has been trying to add a classic Escape Analysis (EA) to HotSpot for quite some time. Its not on by default now. Research from IBM some years ago showed that its really really hard to make EA effective on large program, although it works really well on lots of microbenchmarks.

I cant give perect references right now. Search the internet for Cliff Click and Gil Tene. Specially the talkes.

I remember that on there own hardware the do 'Escape Detection' with costum hardware but the think it would be a win in software as well. I dont know if the have it in software with there new x86_64 VM.

C#'s stackalloc might be useful for some micro-optimizations, but I think it's main purpose is for interop with unmanaged code.

That hadn't occurred to me.

In the late 90s, I cowrote OpenGL bindings for Java, which became the model for jogl and so forth. Whereas other bindings using JNI duplicated the native/C structs, I just carried around the native pointer as a long and used it as an "opaque" pointer. Much less copying (thunking) back and forth.

Rust already does region inference for managing borrowed pointers, so I guess that all the information needed for this is already there.

If you use a Cheney GC, how much does escape analysis help?

Everything that would be stack allocated will die in the first generation, and Cheney's algorithm is indifferent to the amount of garbage.

If nothing else, more heap allocations will cause the collector to run more often.

Absolutely; I was just wondering if anyone knew how big of an impact this would be; all VMs I've used have tiny stacks compared to the size of the heap, so it is academic for many times I would want this.