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

[Doug Simon]

On Thu, 10 Dec 2020 06:29:46 GMT, Jie Fu <jiefu 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.

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

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