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