Faster Object Arrays

1) Won't this have impact on GC implementations ? So any GC implementation needs changes or structured array will only be supported for specific GC implementations.

2) I think the proposal should even go further and might at least add some syntax extensions or at least (if doable) some 'predefined' Annotations to avoid the somewhat 'ugly' clutter when creating truly embedded structured objects.

Overall I'd still prefer "true" structs, however Structured Array seems like an acceptable compromise.

1) To your Question (1) above ("...structured array will only be supported for specific GC implementations?"):

StructuredArray (and subclass-able arrays, and IntrinsicObjects) are already supported on all Java garbage collectors. They just doesn't add any speed benefits on older JVMs. But all of org.ObjectLayout is supported on Java SE 6 and above.

For JVMs that wish to optimize org.ObjectLayout constructs, some modification to the GC mechanisms would be needed for speed gains to occur. Those modifications primarily have to do with keeping instantiated objects "flat" where possible, which mostly means that the collector needs to move containing objects "as a whole". From our work so far, this appears to be a fairly simple thing to add to HotSpot's ParallelGC, CMS, and G1 collectors, and for C4 in Zing. We believe it will also be relatively simple to do in other collectors (e.g. J9's collectors, and Shenandoah), but we haven't spent much time looking into those.

2) We are intentionally avoiding any language changes or extensions, and working to minimize the risk of including the library in the spec and Java name space. Language syntax things, if they make sense, can come in later Java versions. E.g. java.util.concurrent came with no language changes (in Java SE 5) and did very well. It may get some language syntax things with 9 that will help with some of the more cumbersome syntax there (e.g. atomic field updaters).

3) (to your last comment) As I explain at the start of the talk, true structs would be orthogonal to this effort. They will neither replace the need org.ObjectLayout answers [speed. for regular Java Objects. On the heap], or be replaced by it. IBM's packed Java Objects are pretty close to true structs, and I'm carefully staying away from mixing the two, since their goals are orthogonal.

After I login and can download the mp3 of the presentation, I cannot download the slides. I get the following XML (I've replaced proper XML lt and gt with '[]'):

Hi Alexander,
We are aware of the download problem and we are working on solving it.

Hi Alexander,
The problem is now solved and slide download works fine. Thank you for notifying us and for your patience.

Sadly, that doesn't even begin to address java's footprint problem. Memory is cheap, but orders of magnitude still matter.

When common Java applications start to actually use a respectable % of a toy $5K server, (i.e. if common Java apps used more than 100GB of heap in each instance in 2014) I'd agree that it may have a footprint problem. But right now it has an anti-footprint problem: The vast majority of Java application instances use no more than 3-4% of that toy, entry-level server. Our actual industry problem is the vast amount of cheap memory going unused (or only being used for file buffer caching).