RFR: 8213623: ZGC: Let heap iteration walk all roots

Kim Barrett kim.barrett at oracle.com
Fri Nov 9 20:19:42 UTC 2018


> On Nov 9, 2018, at 9:49 AM, Per Liden <per.liden at oracle.com> wrote:
> 
> Let the ZHeapIterator walk all roots, including weak roots that might be logically cleared from the application's point of view. This allows e.g. for a more thorough heap verification.
> 
> Also the heap iterator should access oops with AS_NO_KEEPALIVE to avoid resurrecting object that would otherwise be garbage collected.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8213623
> Webrev: http://cr.openjdk.java.net/~pliden/8213623/webrev.0
> 
> Testing: tier1-4
> 
> /Per

------------------------------------------------------------------------------
src/hotspot/share/gc/z/zRootsIterator.hpp
 127   ZConcurrentRootsIterator(bool marking = false);

Why is this being made optional?  It seems like there is no "safe" or
"obvious" default value, and that all callers should be required to
say what they want.

------------------------------------------------------------------------------
src/hotspot/share/gc/z/zHeapIterator.cpp
 164 void ZHeapIterator::objects_do(ObjectClosure* cl) {
 165   // Note that the heap iterator visits all reachable objects, including
 166   // objects that might be unreachable from the application, such as a
 167   // not yet cleared JNIWeakGloablRef. However, also note that visiting
 168   // the JVMTI tag map is a requirement to make sure we visit all tagged
 169   // objects, even those that might now have become phantom reachable.
 170   // If we didn't do this the application would have expected to see
 171   // ObjectFree events for phantom reachable objects in the tag map.

I think there's a good rationale for walking JNIWeakGlobalRef &etc
here.  But I think that same rationale applies to the other
collectors, and I think all the collectors should be consistent about
this.  Making this semantic change only to ZGC seems wrong to me.

------------------------------------------------------------------------------



More information about the hotspot-gc-dev mailing list