RFC 8233915: JVMTI FollowReferences: Java Heap Leak not found because of C2 Scalar Replacement
Reingruber, Richard
richard.reingruber at sap.com
Mon Nov 11 15:29:36 UTC 2019
Hi,
I have created https://bugs.openjdk.java.net/browse/JDK-8233915
In short, a set of live objects L is not found using JVMTI FollowReferences() if L is only reachable
from a scalar replaced object in a frame of a C2 compiled method. If L happens to be a growing leak,
then a dynamically loaded JVMTI agent (note: can_tag_objects is an always capability) for heap
diagnostics won't discover L as live and it won't be able to find root references that lead to L.
I'd like to suggest the implementation for the proposed enhancement JDK-8227745 as bug-fix.
RFE: https://bugs.openjdk.java.net/browse/JDK-8227745
Webrev(*): http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.1/
Please comment on the suggestion. Dou you see other solutions that allow an agent to discover the
chain of references to L?
I'd like to work on the complexity as well. One significant simplification could be, if it was
possible to reallocate scalar replaced objects at safepoints (i.e. allow the VM thread to call
Deoptimization::realloc_objects()). The GC interface does not seem to allow this.
Thanks, Richard.
(*) Not yet accepted, because deemed too complex for the performance gain. Note that I was able to
reduce webrev.1 in size compared to webrev.0
More information about the hotspot-compiler-dev
mailing list