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

[Leonid Mesnik]

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