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

[Doug Simon]

On Thu, 10 Dec 2020 11:51:44 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   do not synchronize ensure_box_caches_initialized
>
> 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.

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

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