RFR 8247808: Move JVMTI strong oops to OopStorage

[coleen.phillimore at oracle.com]

On 6/17/20 7:49 PM, David Holmes wrote:
> Hi Coleen,
>
> On 18/06/2020 7:25 am, coleen.phillimore at 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