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.
I was thinking about the same.
Relaxing this just for Graal sounds good.
On the other hand, making the test to know about Graal looks a
little bit strange. :)
Thanks,
Serguei
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
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
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
|
