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