I don’t want to make it Graal specific. I think I’ll just do field assignments in native so that it’s all invisible to the compiler.
igor > On Nov 28, 2018, at 3:25 PM, [email protected] wrote: > > On 11/28/18 15:16, [email protected] <mailto:[email protected]> wrote: >> 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 >>> >>> >>> >>>> 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/ >>>>>> <http://cr.openjdk.java.net/%7Eiveresov/8193577/webrev.00/> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8193577 >>>>>> <https://bugs.openjdk.java.net/browse/JDK-8193577> >>>>>> >>>>>> igor >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
