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

[Leonid Mesnik]

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 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