RFR: 8167353: [JVMCI] JVMCI re-initialization check is in the wrong location

[Christian Thalinger]

> On Oct 7, 2016, at 11:30 AM, Doug Simon <doug.simon at oracle.com> wrote:
> 
> 
>> On 07 Oct 2016, at 19:27, Christian Thalinger <cthalinger at twitter.com> wrote:
>> 
>> I’m confused.  Why don’t you need this check anymore?
>> void JVMCIRuntime::initialize_HotSpotJVMCIRuntime(TRAPS) {
>> 
>> -  if (JNIHandles::resolve(_HotSpotJVMCIRuntime_instance) == NULL) {
>> Is this because of a change in Graal? 
> 
> No, it’s because this method this is called exactly once, along this call chain:
> 
> JVMCI.<clinit>
> JVMCI.initializeRuntime
>  JVM_GetJVMCIRuntime  
>   JVMCIRuntime::initialize_HotSpotJVMCIRuntime
> 
> This probably wasn’t true at one point in time.

Oh, ok.  Looks good then.

> 
> 
>> 
>>> On Oct 7, 2016, at 5:17 AM, Doug Simon <doug.simon at oracle.com> wrote:
>>> 
>>> Please review this change that move a guard against JVMCI re-initialization to the right location. The chance of a race causing the check to fail when in the current/wrong location increased recently due to a change in Graal[1] which causes more JVMCI code to be run on application threads.
>>> 
>>> The webrev puts the check in the right place and also converts an assertion to a guarantee for a related check.
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8167353
>>> http://cr.openjdk.java.net/~dnsimon/8167353/
>>> 
>>> -Doug
>> 
>