RFR(XS) 8193577: nsk/jvmti/IterateThroughHeap/filter-tagged fails with Graal in Xcomp mode
dean.long at oracle.com
dean.long at oracle.com
Wed Nov 28 23:16:30 UTC 2018
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.
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.
>> On Nov 28, 2018, at 2:08 PM, Igor Veresov <igor.veresov at oracle.com
>> <mailto:igor.veresov at oracle.com>> 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.
>>> On Nov 28, 2018, at 1:32 PM, dean.long at oracle.com
>>> <mailto:dean.long at oracle.com> 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.
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-compiler-dev