On 2/08/2016 4:46 AM, Kim Barrett wrote:
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.
This change looks good to me.
Thanks,
David
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.]
