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

Reply via email to