The "struct" proposal is all about a) maintaining 100% java language compatibility without introducing *any* wierdness, b) completely removing the object overhead for large collections of mapped objects, and c) putting a nice object oriented front end on top of a flat buffer of memory.
A single instance of a struct has a bytebuffer on which it lives, and a position. A struct is a proper first class object like any other java object; it's passed by reference, it's garbage collected, etc. The only difference is that a struct's primitive fields are not allocated in the heap; instead they are mapped directly into the bytebuffer at the specified position in a consistent well-defined manner. Object fields are ignored for the purposes of the mapping.
What this means is you can have a huge big bytebuffer with a memory-friendly representation of, say, a BSP tree, just like in C or any other sane language. You create an instance of a Node struct, attach it to the bytebuffer, and position it somewhere. Bingo! The Node instance is effectively a pointer to a struct, except it's totally safe
. You can do what the hell you like with your struct instance, it's just another Object.
So that's what structs do.
As for escape analysis - EA is just a really cheap optimisation for a compiler to do. It really is pretty simple to implement. It won't actually bring any speed increases in memory access or reduce object overhead particularly. What it will
do is almost completely eliminate tons of little bits of garbage cluttering up the GC, leaving it to do its work on more important stuff. As a side effect it also means you can guarantee allocation time in many situations which is very important for a lot of people. Excelsior have used EA to very great effect in their JET JVM.