> On Jun 28, 2016, at 4: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 :)
A related post in compiler-dev w.r.t. Reference<? super Object>: http://mail.openjdk.java.net/pipermail/compiler-dev/2014-January/008457.html Looks like no reply on that thread though. > >> 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) > How do you get this list? > 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. > Do you mind trying b110 before JEP 261 was integrated in jdk-9+111 and see any difference? initPhase1 is expected to be called very early in the VM initialization after the primordial classes are loaded. IIRC, the exception classes are preallocated to improve diagnosability in the case when we run out of memory VM can still throw a preallocated instance with an preallocated stack trace buffer. I don’t think these exception classes are expected to be loaded initPhase1. More to dig here. Mandy > 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. > > Thanks, > David >
