RFC 8233915: JVMTI FollowReferences: Java Heap Leak not found because of C2 Scalar Replacement

[Reingruber, Richard]

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 at openjdk.java.net> On Behalf Of Leonid Mesnik
Sent: Dienstag, 12. November 2019 20:34
To: hotspot-compiler-dev at 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