On 2019-03-14 10:21, Erik Helin wrote:
On 12 Mar 2019, at 16:19, Stefan Karlsson <stefan.karls...@oracle.com> wrote:
Hi all,
Hey StefanK,
Please review and/or comment on this change to remove
CodeCache::scavenge_root_nmehods_do from
VM_HeapWalkOperation::collect_simple_roots.
http://cr.openjdk.java.net/~stefank/8220342/webrev.01/
I think this patch makes sense, removing the call
CodeCache::scavenge_root_nmethods_do makes the semantics of the JVMTI
operations you mentioned much more clear. Reviewed.
Thanks!
On 12 Mar 2019, at 16:19, Stefan Karlsson <stefan.karls...@oracle.com> wrote:
There has been some brief, internal discussions that maybe we want to visit all
sets of roots in the vm, both strong and weak. A quick
implementation of that causes problem in testing when objects tagged by JVMTI,
and JNI weak global handles, gets reported as roots.
Because of that, such change requires more investigation and work than simply
extending the set of roots.
It would be nice if we could add a note somewhere about how HotSpot interprets
“...and other objects used as roots for the purposes of garbage collection” in
the JVMTI specification. As you have highlighted, and as we discussed, this
wording in the JVMTI specification is not precise enough. Different GC
algorithms (and different phases of a single GC algorithm) often have different
root sets, rendering the wording “…objects used as roots for the purpose of
garbage collection” unclear, since the “objects used as roots” can differ
depending on GC algorithm and phase. An implementation of the JVMTI
specification has to interpret this sentence and choose which objects to
include in the root set for these JVMTI operations. I think it would be helpful
for HotSpot JVMTI users if there is a place where we could document which
objects HotSpot includes in this root set (we should preferably use the same
set of root objects for all GC algorithms).
Should we create a hotspot/jvmti RFE for this?
StefanK
Thanks,
Erik