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

[Jie Fu]

On Thu, 10 Dec 2020 13:00:36 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 950:
>> 
>>> 948:   if (_has_auto_box) {
>>> 949:     JavaThread* THREAD = JavaThread::current();
>>> 950:     JVMCI::ensure_box_caches_initialized(JVMCI_lock, CHECK_(JVMCI::ok));
>> 
>> Why we can hold JVMCI_lock here.
>> Does it mean that we'll never initialize the box classes at this point?
>
> 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

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

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