> On Jun 28, 2016, at 7:23 PM, David Holmes <david.hol...@oracle.com> wrote: > > On 29/06/2016 8:43 AM, Kim Barrett wrote: >> Updated webrevs: >> >> Full: >> http://cr.openjdk.java.net/~kbarrett/8156500/jdk.01/ >> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.01/ >> >> Incremental: >> http://cr.openjdk.java.net/~kbarrett/8156500/jdk.01.inc/ > > Did Reference<?> not work? Just curious. I used to be a qualified Java > programmer back in the Java 5 era, but wildcards were always a bit iffy :)
It did not, or at least not without more contortions than I wanted to make. The old code used <Object>, so I decided to fall back to that. Specifically, the type parameter in the type of "ref" needs to be compatible with the type parameter in the type of "q", and that seems to be messy to make happen when wildcards are involved. Having popXXX return Reference<? extends Object> and splitting most of the body of tryHandlePending into a new parameterized helper <S> boolean tryHandlePendingAux(Reference<S> ref, boolean should_wait) did seem to do the trick, but also seemed like it was trying too hard... >> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.01.inc/ >> >> Still investigating the initialization order for core exceptions. > > I suspect it is as Coleen indicated that the module changes introduced the > new failure path that you hit. I did a quick check of the initialization > order in an old b50: > > 33 Initializing 'java/lang/Throwable' (0x0000001780002990) > ... > 46 Initializing 'java/lang/Exception'(no method) (0x0000001780003158) > 47 Initializing 'java/lang/InterruptedException'(no method) > (0x00000017800178a8) > > Compare that with a current build: > > 60 Initializing 'java/lang/ref/Reference$ReferenceHandler' > (0x000000080001e3f0) > 61 Initializing 'java/lang/Throwable' (0x00000008000029f8) > 62 Initializing 'java/lang/Exception'(no method) (0x00000008000031a8) > 63 Initializing 'java/lang/InterruptedException'(no method) > (0x000000080001e6e0) > 64 Initializing 'java/lang/ref/PhantomReference'(no method) > (0x0000000800006440) > > Initialization of Throwable is much, much later (large parts of java.lang and > java.util are now initialized first!) and is obviously a direct consequence > of preinitializing InterruptedException. > > So I would say that the module change did break this and that initialization > of Throwable (only) should be restored to a much higher place in the > initialization sequence. I think the problem may have existed long before modules, but simply wasn't noticed. That is, I suspect trying the test case mentioned below with a pre-June-2014 fastdebug build (when Reference started initializing InterruptedException) might trip the same assert. I'm presently trying to obtain a sufficiently old fastdebug build to run the experiment. The thing that has changed is that we now have a test (ol' reliable tickler of bugs TestOptionsWithRanges) that tries all kinds of wacky configurations that had never been seen before. It tripped the init order problem by trying -XX:AutoBoxCacheMax with a value of jint_max, which led to an attempt to allocate an array whose size exceeds the maximum allowed, which is reported as OOME with a specialized message, which led to the assertion failure in java_lang_Throwable::fill_in_stack_trace_of_preallocated_backtrace because java_lang_Throwable::unassigned_stacktrace() == NULL. Note that with a smaller -XX:AutoBoxCacheMax value of 1G we instead get a VM shutdown during initialization, because we are trying to GC before that's allowed, rather than trying to make an array with an impossible size. Aside: Reporting an attempt to allocate a mere 2G element objarray using an OOME seems a bit quaint these days. :-)
