RFR: 8227653: Add VM Global OopStorage

[Vladimir Kozlov]

Thank you, Kim

Good. Please file bug for JDK 13 and assign it to me. I will port your JVMCI fix.

Thanks,
Vladimir

On 7/17/19 3:48 PM, Kim Barrett wrote:
>> On Jul 16, 2019, at 11:52 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>
>> Here goes my work for JVMCI oops handling ;)
> 
> Yeah, sorry about that.  I think I went on vacation in the middle of
> the review of those changes.
> 
>> Kim, after this change the only use for JVMCI::_object_handles is JVMCI::is_global_handle() which is only used in assert() in deleteGlobalHandle() in jvmciCompilerToVM.cpp. Do we really need it there? May be we should remove this use too.
> 
> I hadn't looked through the uses carefully, assuming replacement of
> one OopStorage with another wouldn't uncover any problems.
> 
> Unfortunately, it turns out there's a pre-existing bug lurking.
> 
> JVMCI::_object_handles is also used by JVMCI::make_global, not
> surprisingly.  What did surprise me is the lack of a corresponding
> destroy function.  And then I looked at deleteGlobalHandles() in
> jvmciCompilerToVM.cpp, and it seems to have not been updated from the
> old JNIHandleBlock implementation when these global handles were
> changed to use OopStorage.  So instead of calling OopStorage::release,
> deleteGlobalHandles just leaks the handles.
> 
> I'm posting the fix for this as an incremental change on my
> JDK-8227653 change, but I'm wondering if it ought to be split out into
> a separate bug fix for JDK 13.
> 
> Webrevs:
> full: http://cr.openjdk.java.net/~kbarrett/8227653/open.01/
> incr: http://cr.openjdk.java.net/~kbarrett/8227653/open.01.inc/
> 
> Testing:
> mach5 hs-tier3-5 (in progress), which do some graal testing.
>