8258015: [JVMCI] JVMCI_lock shouldn't be held while initializing box classes #1727
Conversation
|
👋 Welcome back jiefu! A progress list of the required criteria for merging this PR into |
|
/issue add JDK-8258015 |
|
@DamonFool This issue is referenced in the PR title - it will now be updated. |
|
@DamonFool |
|
@DamonFool The |
|
Yes, seems like, we can safely get rid of this lock since the init state change in InstanceKlass is already under a lock. Worst case scenario we do that loop a few times. @dougxc, what do you think? Alternatively, we can drop the checks of the initialized flag for AOT entirely. |
| @@ -130,11 +130,6 @@ void JVMCI::ensure_box_caches_initialized(TRAPS) { | |||
| if (_box_caches_initialized) { | |||
| return; | |||
| } | |||
| MutexLocker locker(JVMCI_lock); | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
OK. Please feel free to do so.
Thanks.
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
Progress
Issue
Download
$ git fetch https://git.openjdk.java.net/jdk pull/1727/head:pull/1727$ git checkout pull/1727