RFR: 8227653: Add VM Global OopStorage

Thomas Schatzl thomas.schatzl at oracle.com
Tue Jul 16 09:25:32 UTC 2019


Hi,

On Mon, 2019-07-15 at 21:18 -0400, 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/

 looks good to me.

Thomas




More information about the hotspot-dev mailing list