This updated webrev addresses the concerns around initialization order for Throwable and OutOfMemoryError. It doesn't address the VM API used by the reference processor thread; that will be in a later webrev.
New webrevs: full: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.02/ incr: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.02.incr/ The jdk tree is unchanged from webrev.01. I've backed out the change to initialize_java_lang_classes. (To verify this, look at the runtime/thread.cpp in the full webrev.) Instead, Universe::gen_out_of_memory_error now also requires Throwable to be initialized before it will attempt to fill in the stack trace. This means that VM generated OOMEs occurring early in initialization won't have a stack trace. An alternative that I considered was to remove the assert at the end of fill_in_stack_trace_of_preallocated_backtrace that requires java_lang_Throwable;:unassigned_stacktrace() to return non-NULL. I did some testing that seemed to work and provide stacktraces, relying on code in the Throwable class that special cases this "out of protocol" state. However, having read some of the history around that (JDK-6998871, JDK-7045138, JDK-7046490), that special casing seems to have been intended to be temporary, and expected to be removed. (Though I didn't find an RFE for doing so, and I'm not doing so here.) Even if we decided it wasn't going to be removed, this approach seems somewhat fragile. [Note to Coleen: This is the reverse of what you and I talked about a few days ago; I hadn't reviewed the history carefully then.]