RFR 8247808: Move JVMTI strong oops to OopStorage

[coleen.phillimore at oracle.com]

Thanks Ioi.

On 6/18/20 2:02 AM, Ioi Lam wrote:
> 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.

Yes, someone who works on G1 more can think about that.
thanks,
Coleen
>
> 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
>>
>