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

Doug Simon doug.simon at oracle.com
Fri Oct 7 21:30:31 UTC 2016


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


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



More information about the hotspot-compiler-dev mailing list