RFR: 8242440: use separate, destroyable JavaVM instances per libgraal compiler thread [v3]

[Doug Simon]

On Fri, 22 Apr 2022 05:10:16 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed (incorrect) volatile modifier from JVMCIRuntime::_shared_library_javavm
>
> src/hotspot/share/jvmci/jvmciRuntime.cpp line 895:
> 
>> 893:     ResourceMark rm;
>> 894:     oop** ptrs = NEW_RESOURCE_ARRAY(oop*, _oop_handles.length());
>> 895:     for (int i = 0; i < _oop_handles.length(); i++) {
> 
> Now that _oop_handles is a vector of `oop*`, the resource allocation and
> possibly some copying could be avoided. Do an in-place removal of nullptr and
> clearing of the values pass over the vector, and then use
> 
> object_handles()->release(_oop_handles.at_ptr(0), _oop_handles.length())
> 
> For future, I wonder if it would be worth changing OopStorage bulk release to ignore nullptrs in the array, to better support this kind of use-case.  But I'm not sure how common this kind of use-case (array of handles, some of which might be nullptr) really might be.  I think there are only a couple uses of bulk release so far.

Nice suggestion on avoiding resource allocation: https://github.com/openjdk/jdk/pull/8262/commits/385880c2bf0343aee8166c6bc45446e0033c876b

I don't think it's worth changing OopStorage bulk release for this use case.

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

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