RFR 8247808: Move JVMTI strong oops to OopStorage

[coleen.phillimore at oracle.com]

Thank you Zhengyu.
Coleen

On 7/15/20 2:35 PM, Zhengyu Gu wrote:
> Hi Coleen,
>
> Shenandoah part looks good.
>
> Thanks,
>
> -Zhengyu
>
> On 7/15/20 11:38 AM, coleen.phillimore at oracle.com wrote:
>>
>> Hi, This patch has been reviewed and I was waiting for the ability to 
>> define different OopStorages, but I'd like to fix that in a further 
>> change after the GC changes have been agreed upon and reviewed.  
>> Adding a new JVMTI OopStorage in the new mechanism is a smaller change.
>>
>> open webrev at 
>> http://cr.openjdk.java.net/~coleenp/2020/8247808.01/webrev
>>
>> Retested with tier1-3.
>>
>> Thanks,
>> Coleen
>>
>>
>>
>> On 6/18/20 3:48 PM, coleen.phillimore at oracle.com wrote:
>>>
>>>
>>> On 6/18/20 3:58 AM, Thomas Schatzl wrote:
>>>> Hi,
>>>>
>>>> On 18.06.20 03:09, 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.
>>>>>>>
>>>> [...]
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>> I do not know which exact roots you want to move into OopStorage, 
>>>> but I would like to mention this concern: with moving everything 
>>>> into a single OopStorage (i.e. vm_globals in this case), I am 
>>>> worried that every time important information about the source for 
>>>> these gets lost.
>>>>
>>>> Which makes it hard to understand from where these oops came from 
>>>> when there is a performance problem in the "VM Globals" bucket.
>>> Hi Thomas,
>>>
>>> I understand this concern.  On the GC list there is a discussion 
>>> about having the ability to create different strong OopStorages, 
>>> changing the OopStorage code to process these roots and report 
>>> statistics in parallel (and/or concurrent), and not having to 
>>> cascade the code through all the GCs.
>>>
>>> I'm going to hold this change until this discussion is complete and 
>>> move the JVMTI and services/management oops_do oops into a different 
>>> OopStorage that can make use of this. Then you'll have your 
>>> statistics and we won't have classes needing traversal with oops_do.
>>>
>>> Thanks,
>>> Coleen
>>>
>>>>
>>>> This may not apply to JVMTI oops, but others may occasionally have 
>>>> a significant amount of oops where it would be very interesting to 
>>>> know from where a particular slowdown comes from.
>>>>
>>>> So I would prefer keep some accounting here.
>>>>
>>>> Thanks,
>>>>   Thomas
>>>
>>
>