RFR: 8161274: [JVMCI] compiler/jvmci/events/JvmciNotifyInstallEventTest.java fails with NoClassDefFound

[Doug Simon]

Graal testing revealed a problem introduced by this path in -Xbatch mode: JVMCI is force initialized before the system class loader has been initialized.

I’ve uploaded a new webrev that addresses this:

http://cr.openjdk.java.net/~dnsimon/8161274.v3

In particular:

http://cr.openjdk.java.net/~dnsimon/8161274.v3/src/share/vm/runtime/thread.cpp.sdiff.html

-Doug

> On 13 Jul 2016, at 21:42, Doug Simon <doug.simon at oracle.com> wrote:
> 
> 
>> On 13 Jul 2016, at 20:47, Christian Thalinger <cthalinger at twitter.com> wrote:
>> 
>> 
>>> On Jul 13, 2016, at 5:36 AM, Doug Simon <doug.simon at oracle.com> wrote:
>>> 
>>> Please review this fix for a failure under -TieredCompilation caused by an attempt to compile with JVMCI before the VM is sufficiently booted to initialize JVMCI. This is the same problem addressed by JDK-8160121. The only problem is that the fix was too localized - it only applied on tiered compilation paths. The proper fix is to test for JVMCI compilabilty in CompileBroker::compile_method.
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8161274
>>> http://cr.openjdk.java.net/~dnsimon/8161274/
>> 
>> What about the other CompileBroker::compile_method method?  Right now it’s only called by the method you are guarding but it’s a public method so anyone could.
> 
> I assume the overload (which I missed) was introduced purely to add the DirectiveSet argument in which case the original method should have probably been made private. However, it wasn’t so I’ve moved the guard as you imply I should:
> 
> http://cr.openjdk.java.net/~dnsimon/8161274.v2
> 
> -Doug
> 
>