RFR(XS) 8193577: nsk/jvmti/IterateThroughHeap/filter-tagged fails with Graal in Xcomp mode

[dean.long at oracle.com]

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 <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.
>>
>> igor
>>
>>
>>> 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[].
>>>
>>> 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
>>>>
>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20181128/9ad69e53/attachment.html>