RFR(XS) 8193577: nsk/jvmti/IterateThroughHeap/filter-tagged fails with Graal in Xcomp mode
Igor Veresov
igor.veresov at oracle.com
Wed Nov 28 22:12:28 UTC 2018
I don’t see a better way, really. If there is a less hacky way that is allowed by the iteration API, I’m definitely open to suggestions.
igor
> On Nov 28, 2018, at 1:27 PM, serguei.spitsyn at oracle.com wrote:
>
> Hi Igor,
>
> It looks like a hack but Okay with me.
>
> Thanks,
> Serguei
>
>
> On 11/28/18 13:13, 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/hotspot-compiler-dev/attachments/20181128/64824dc0/attachment-0001.html>
More information about the hotspot-compiler-dev
mailing list