RFR: 8258015: [JVMCI] JVMCI_lock shouldn't be held while initializing box classes

[Jie Fu]

On Thu, 10 Dec 2020 09:22:40 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> Hi all,
>> 
>> Plenty of AOT tests failed after JDK-8257917.
>> The reason is that JVMCI_lock [1] was held during box classes initilization.
>> However, this assert [2] doesn't allow a lock (except tty_lock [3]) to be held in that case.
>> So JVMCI_lock here [1] should be removed.
>> 
>> Testing:
>>   compiler/aot and compiler/jvmci on Linux/x64
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/jvmci/jvmci.cpp#L133
>> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/thread.cpp#L795
>> [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/mutex.cpp#L440
>
> src/hotspot/share/jvmci/jvmci.cpp line 133:
> 
>> 131:     return;
>> 132:   }
>> 133:   MutexLocker locker(JVMCI_lock);
> 
> This lock is required in the case where this is not called from `AOTLoader::initialize_box_caches` to ensure only one JVMCI compiler thread does the lazy initialization.
> I can fix this if you'd like me to put up a separate PR.

OK. Please feel free to do so.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1727