Anyone wanting to re-evaluate the currently disabled layout variants should consider pulling the fixes from commit 1c0b76decd09da5a6da8e57b36115a4fb92ff747.

The performance degradation was down to seeing if an entry was contained in the pending entries. Adding a flag to the entry avoids this slow down and performance is identical to without the patch. Variant of patch committed in r14876 due to the many changes that happen to BootImageWriter in the build up to 3.0.

re-read all the comments...missed the earlier data., Slowing down bootimage writing by 50% now to gain flexibility/.parallalization later is not an acceptable trade off in my opinion. -1 on this patch from me until performance issues addressed.

I don't see a rush to apply this patch. The bootimage writer historically has changed very slowly, so the risk of patch rot in the next month or two seems very low.

One should at least have empirical data for bootimage writing time with and without the patch applied for writing a prototype, development, and production image so that we can make an empirically guided decision.

I'm honestly less worried about slowing bootimage writing by a few percent than by the increase in stack depth causing problems for the host JVM and limiting our ability to build some configurations on some platforms. Can you quantify how much bigger the stacks need to be (run with different thread stack sizes for the host JVM with and without the patch and see where you start to get stack overflows).

3) is completely true, but also completely orthogonal to the question of whether or not this patch should be applied to the head or put in the research archive.

It's also not clear to me why this patch is worth prioritizing above the many other items sitting against 2.9.4 and 3.0.

As a research virtual machine I think its important that as few design decisions as possible are baked in, hence working to put flexibility back into how we configure the object model. The patch separates out the writing of reference fields in the boot image to a method of its own, this extra stack frame puts pressure on the stack and slows a purely depth first approach. However, one benefit of this approach could be to allow the traversal of the object graph to be parallelized. As well as memory overhead the patch inserted extra assertions, to check for example, a JTOC entry being read as an int was actually numeric. These assertions make sense and usefully capture invariants about the code, they do come at a build time and runtime cost in all but production builds. I think 3 things stem from this:

1) apply the patch, we shouldn't have an inflexible design and the research tracker will cause the patch to bit rot
2) parallelize the traversal of the object graph to speed boot image writing (you can't do this without 1)
3) look to improve our assertion mechanism, having a single global boolean probably isn't sensible - we should probably make assertions particular to the module they are within and then have some kind of defense condition (defcon) status for which assertions should be checked