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

[Doug Simon]

On Thu, 10 Dec 2020 13:45:58 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> I'm not sure I understand your question - why would we not be able to hold JVMCI_lock here?
>> That said, based on @veresov 's [earlier comment](https://github.com/openjdk/jdk/pull/1727#issuecomment-742381965), I'm now inclined to remove the lock altogether. As he says, at worst we harmlessly execute the loop in `ensure_box_caches_initialized` a few extra times. I've pushed this change.
>
> I think we should not hold JVMCI_lock here, because:
> 
>   If JVMCI_lock was acquired, then no_safepoint_verifier(new_owner, true) was called [1].
>      --> Then, thread->_no_safepoint_count was increased [2].
>          --> Then, the assert [3] would fail due to _no_safepoint_count > 0.
> 
> What do you think?
> Thanks.
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/mutex.cpp#L480
> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/mutex.cpp#L446
> [3] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/thread.cpp#L795

Yes, you're right - a VM lock should not be held when leaving the VM to call Java code.
As stated above, I've removed the lock altogether now (91571c1b3783fe2a2591d65a62fbf8286be173d9).

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

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