RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java

[David Holmes]

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.]
>