Hi Leonid, these are valid points. Thanks for making me aware of them.
I've increased the maximum heap size in my tests as suggested, and I've also run them with ZGC enabled. I've also added the vm.opt.TieredCompilation != true requirement. I've done the changes in place. Thanks, Richard. -----Original Message----- From: hotspot-compiler-dev <hotspot-compiler-dev-boun...@openjdk.java.net> On Behalf Of Leonid Mesnik Sent: Dienstag, 12. November 2019 20:34 To: hotspot-compiler-...@openjdk.java.net Subject: Re: RFC 8233915: JVMTI FollowReferences: Java Heap Leak not found because of C2 Scalar Replacement Hi I don't make complete review just sanity verified your test headers. I see a couple of potential issues with them. 1) The using Xmx32M could cause OOME failures if test is executed with ZGC. I think that at least 256M should be set. Could you please verify that your tests pass with ZGC enabled. 2) I think it makes sense to add requires vm.opt.TieredCompilation != true to just skip tests if anyone runs them with tiered compilation disabled explicitly. Leonid On 11/11/19 7:29 AM, Reingruber, Richard wrote: > 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
