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 <[email protected]> On
Behalf Of Leonid Mesnik
Sent: Dienstag, 12. November 2019 20:34
To: [email protected]
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
