RFR: 8227653: Add VM Global OopStorage

[Kim Barrett]

> 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.