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