[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFC 8233915: JVMTI FollowReferences: Java Heap Leak not found because of C2 Scalar Replacement
From:       Leonid Mesnik <leonid.mesnik () oracle ! com>
Date:       2019-11-13 16:42:18
Message-ID: b6ce6d77-3c9c-c978-3fc5-586717089ec8 () oracle ! com
[Download RAW message or body]

Thank you for fixing this.

Leonid

On 11/13/19 4:24 AM, Reingruber, Richard wrote:
> 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-bounces@openjdk.java.net> On \
>                 Behalf Of Leonid Mesnik
> Sent: Dienstag, 12. November 2019 20:34
> To: hotspot-compiler-dev@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


[prev in list] [next in list] [prev in thread] [next in thread]