On 6/17/20 7:49 PM, David Holmes wrote:
Hi Coleen,
On 18/06/2020 7:25 am, coleen.phillim...@oracle.com wrote:
Summary: Remove JVMTI oops_do calls from JVMTI and GCs
Tested with tier1-3, also built shenandoah to verify shenandoah changes.
open webrev at
http://cr.openjdk.java.net/~coleenp/2020/8247808.01/webrev
bug link https://bugs.openjdk.java.net/browse/JDK-8247808
This is a nice cleanup and simplification of the code for working with
OopStorage! So LGTM.
Thanks, David.
One query ... I'm assuming that the processing previously done in
JvmtiExport::oops_do is now done by
OopStorageSet::vm_global()->oops_do. In most cases I can see the call
to OopStorageSet::vm_global()->oops_do in the same vicinity as the
call to JvmtiExport::oops_do, but not all i.e. ZRootsIterator::oops_do
and ShenandoahSerialRoots::oops_do. Tracking through it seems that for
those GCs the VM global roots are processed concurrently, whereas
currently JVMTI roots are not. Does that make any potential difference?
ZGC and Shenandoah are better because when the vm_global() roots grow,
they'll be processed faster. Because accessing oops in OopStorage uses
resolve() which uses the Access API, any oops will be marked or fixed
when accessed if the GC hasn't yet gotten to this oop in it's concurrent
processing.
Kim noticed that G1 and ParallelGC should be processing these roots in
parallel (with many threads, since OopStorage has that support) and he's
going to or has filed a bug to fix it. As we add more things to
OopStorage (see upcoming RFRs), this will become important.
Thanks,
Coleen
Thanks,
David
-----
Thanks,
Coleen
