RFR/RFC: 8220342: Remove scavenge_root_nmethods_do from VM_HeapWalkOperation::collect_simple_roots
stefan.karlsson at oracle.com
Tue Mar 12 15:19:48 UTC 2019
Please review and/or comment on this change to remove
VM_HeapWalkOperation::collect_simple_roots is used to implement the
following JVMTI functionality:
"This function initiates a traversal over the objects that are directly
and indirectly reachable from the specified object or, if initial_object
is not specified, all objects reachable from the heap roots. The heap
root are the set of system classes, JNI globals, references from thread
stacks, and other objects used as roots for the purposes of garbage
The set of roots in collect_simple_roots matches this, and mostly visits
the set of roots that one of our class unloading enabled GCs would visit.
There are some roots missing. For example:
And there's one set of roots that is present in collect_simple_roots,
that is not visited by our unloading GCs:
As an example, in PSMarkSweep we have the following comment in the root
// Do not treat nmethods as strong roots for mark/sweep, since we can
The CodeCache::scavenge_root_nmethods_do is only used by Serial,
Parallel, and CMS, to scan pointers into young gen. Other GCs don't use
it at all, and if we run with G1 this call does nothing at all.
CodeCache::scavenge_root_nmethods_do is an GC implementation detail that
I want to confine with the following RFE:
"Move scavenge_root_nmethods from shared code"
and this is the only external usage of it.
Note also that the only effect of this code is that it adds a set of
roots that point into the young gen, but only for some of our GCs. There
are other roots that also point into the young gen that we don't visit.
For example, the non-system classes. See how collect_simple_roots use
ClassLoaderDataGraph::always_strong_cld_do instead of
I've run through tier1-7 with this removal, without any problems.
I'd be interested in hearing if others have a justification for having
this code in collect_simple_roots. Or a test-case showing why this is
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. However, if one were to go that route the
above call to CodeCache::scavenge_root_nmethods_do would be replaced
with CodeCache::blobs_do, the function used when we turn off class
unloading and use our weak roots as strong roots. As an example, see
// CMSCollector uses this to do intermediate-strength collections.
// We scan the entire code cache, since CodeCache::do_unloading
is not called.
More information about the hotspot-gc-dev