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

[Per Liden]

FYI, I've just pushed a patch[1] that makes ZGC work better with smaller 
heaps (down to 8M).

[1] 
https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-November/027844.html

/Per

On 11/12/19 8:33 PM, Leonid Mesnik wrote:
> 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