RFR 8247808: Move JVMTI strong oops to OopStorage

[Thomas Schatzl]

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.

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