RFR: 8227653: Add VM Global OopStorage

[Vladimir Kozlov]

Here goes my work for JVMCI oops handling ;)

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.

Thanks,
Vladimir

On 7/15/19 6:18 PM, Kim Barrett wrote:
> Please review this change which adds a VMGlobal OopStorage object.  It
> is initially being used instead of the conditional JVMCI global storage
> object, which is being removed.
> 
> Looking for reviewers from all of gc, runtime, and compiler.
> 
> To keep things simple for now, this new storage object is (optionally)
> included in the processing done by SystemDictionary::oops_do.  Most
> existing storage processors use that mechanism.  For most processors,
> that's consistent with how JNI global handles are processed.  ZGC uses
> a different approach, and provides enough infrastructure that it was
> easy to process this new storage object in a way that is consistent
> with ZGC's handling of JNI globals.
> 
> This change does not attempt to address the problems around changing
> the set of OopStorage instance described by JDK-8227054.  This change
> was a useful bit of preparation for the work I'm doing on JDK-8227054,
> so I split it out as a separate change.
> 
> This change also includes a minimal update of Shenandoah, using the
> processing of the new storage object by SystemDictionary::oops_do.
> It looks like Shenandoah is conceptually similar to ZGC in it's
> handling of JNI globals, and should be able to handle this new storage
> object similarly, but I'm leaving that to the Shenandoah developers.
> You might want to wait for JDK-8227054 though.
> 
> Note that neither ZGC nor Shenandoah processed the former conditional
> JVMCI global storage.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8227653
> 
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8227653/open.00/
> 
> Testing:
> mach5 tier1-5
>