Alright, how about the following solution: http://cr.openjdk.java.net/~iveresov/8193577/webrev.01/
igor > On Nov 28, 2018, at 4:59 PM, Igor Veresov <[email protected]> wrote: > > 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] >> <mailto:[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 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
