RFR (S) 8251302: Create dedicated OopStorages for Management and Jvmti

[Coleen Phillimore]

On 8/10/20 4:38 PM, serguei.spitsyn at oracle.com wrote:
> On 8/10/20 13:34, serguei.spitsyn at oracle.com wrote:
>> Hi Coleen,
>>
>> It looks good to me.
>> Minor:
>> +void JvmtiExport::initialize_oop_storage() {
>> + // OopStorage needs to be created early in startup and unconditionally
>> + // because of OopStorageSet static array indices.
>> + _jvmti_oop_storage = OopStorageSet::create_strong("Thread OopStorage");
>> +}
>> +
>> Would it better to replace "Thread Oopstorage" with "JVMTI OopStorage"?
>
> In the file
> http://cr.openjdk.java.net/~coleenp/2020/8251302.01/webrev/test/jdk/jdk/jfr/event/gc/collection/TestG1ParallelPhases.java.udiff.html
> I see this:
>               "Thread OopStorage",
> + "ThreadService OopStorage",
> It is not clear if we can simply add ""JVMTI OopStorage" above.

Serguei,  Thank you for finding this.  I was wondering why I didn't have 
to add JVMTI OopStorage to the test.  I'd cut/pasted the same string for 
Thread OopStorage.

I'll fix this and the test and retest.

thanks,
Coleen
>
> Thanks,
> Serguei
>
>
>> No need in another webrev.
>>
>> Thanks,
>> Serguei
>>
>> On 8/10/20 12:37, Coleen Phillimore wrote:
>>> These OopHandles are created and released during breakpoints and 
>>> Thread stack walking operations.  They should have their own 
>>> OopStorage so that GC can detect whether these things affect timing.
>>>
>>> Tested with tier1-6.
>>>
>>> open webrev at 
>>> http://cr.openjdk.java.net/~coleenp/2020/8251302.01/webrev
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8251302
>>>
>>> Thanks,
>>> Coleen
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20200810/66cae666/attachment-0001.htm>