On 8/10/20 4:38 PM, serguei.spit...@oracle.com wrote:
On 8/10/20 13:34, serguei.spit...@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
