RFR 8247808: Move JVMTI strong oops to OopStorage

[Ioi Lam]

Hi Coleen,

This looks good to me.

G1GCPhaseTimes::phase_name and enum GCParPhases should really be defined 
using an X-macro, but that's a different RFE.

Thanks
- Ioi

On 6/17/20 6:09 PM, coleen.phillimore at oracle.com wrote:
>
>
> 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
>