It sounds like the test could also fail with C2 if the fields are in a
virtual object that was eliminated. I'm OK with your fix, but I would
feel a little better if we only relaxed the check for Graal. I guess
you'd need to use the whitebox api for that.
dl
On 11/28/18 2:28 PM, Igor Veresov wrote:
Oh, I haven’t understood your idea before pressing reply. Yes, we can
match the objects by matching their shape, but it’s also not an exact
solution prone to erroneous matches. Especially considering the
iteration API does callbacks for the fields out of order - it does
primitives, strings, arrays, in that order.
There are also ways to make it fail with Graal that are not related to
constant representation. Graal treats allocations as side effect free.
So it’s possible to allocate something and then deopt to a point
before the allocation and redo the allocation in the interpreter. In
this case there are going to be multiple objects on the heap with only
one of them being reachable.
igor
On Nov 28, 2018, at 2:08 PM, Igor Veresov <[email protected]
<mailto:[email protected]>> wrote:
I don’t think there is a way to identify an untagged object. There is
nothing that is passed in the callback to allow that.
igor
On Nov 28, 2018, at 1:32 PM, [email protected]
<mailto:[email protected]> wrote:
I'm guessing Graal creates Constant boxes of the individual fields
and not of the test objects? If so, can't we fix the matching so
that it checks that all fields of an object match? I guess that
would mean moving the "expected" and "found" counts up from fields[]
to objects_info[].
dl
On 11/28/18 1:13 PM, Igor Veresov wrote:
When doing heap iteration with JVMTI the way the object identity is
tracked is by tagging. This particular test checks if it can
observe an untagged object. Since there is no way to truly track
the identity of an untagged object the test validates the identity
by checking the value of the fields of such object. When being
compiled with Graal there are objects produced (such as Constant
boxes) that have field values that are equal to the expected values
for the fields in UntaggedClass. During the subsequent heap
iteration these objects are reported to the test and are treated as
if they were instances of UntaggedClass.
The fix is to relax the test requirement and allow (for the
untagged case) the number of the object found during iteration to
be more than expected.
Webrev: http://cr.openjdk.java.net/~iveresov/8193577/webrev.00/
JBS: https://bugs.openjdk.java.net/browse/JDK-8193577
igor
