Thank you for the review.
On 7/16/20 2:39 AM, David Holmes wrote:
Hi Coleen,
On 16/07/2020 1:38 am, coleen.phillim...@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
This all looks okay to me.
I think you missed updating
share/gc/shared/genCollectedHeap.hpp
to delete
GCH_PS_jvmti_oops_do,
I did miss that. Looks like someone forgot to remove
GCH_PS_FlatProfiler_oops_do also.
Thanks,
Coleen
Thanks,
David
-----
Retested with tier1-3.
Thanks,
Coleen
On 6/18/20 3:48 PM, coleen.phillim...@oracle.com wrote:
On 6/18/20 3:58 AM, Thomas Schatzl wrote:
Hi,
On 18.06.20 03:09, coleen.phillim...@oracle.com wrote:
On 6/17/20 7:49 PM, David Holmes wrote:
Hi Coleen,
On 18/06/2020 7:25 am, coleen.phillim...@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
