RFR(S): 8221083: [ppc64] Wrong oop compare in C1-generated code

[Volker Simonis]

On Fri, Mar 22, 2019 at 4:47 PM Doerr, Martin <martin.doerr at sap.com> wrote:
>
> Hi Volker,
>
> thanks for the updated test.
>
> Looks like there are still a few leftovers from earlier experiments. I don't see any usage of Unsafe.
> Not sure if all options and @modules etc. are still required.
>

You're right :) Unsafe isn't required any more:

http://cr.openjdk.java.net/~simonis/webrevs/2019/8221083.v2

> If you have time, it would be nice to clean up a little bit.
>
> Best regards,
> Martin
>
>
> -----Original Message-----
> From: Volker Simonis <volker.simonis at gmail.com>
> Sent: Freitag, 22. März 2019 14:48
> To: Doerr, Martin <martin.doerr at sap.com>
> Cc: Florian Weimer <fw at deneb.enyo.de>; hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
> Subject: Re: RFR(S): 8221083: [ppc64] Wrong oop compare in C1-generated code
>
> Hi Florian, Martin,
>
> thanks for looking at the change.
>
> I think Martin is right, we either get an object allocated at
> 0x700000000 right with the first allocation after System.gc() or it is
> unlikely that we'll get it at all. The loops are actually a leftover
> from my first experiments with other GC's like G1, but in the end I
> decided to explicitly use SerialGC because it was the simplest and
> most reliably way of allocation an object at the desired address.
>
> Please find the new webrev here:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2019/8221083.v1/
>
> Thank you and best regards,
> Volker
>
> On Wed, Mar 20, 2019 at 12:24 PM Doerr, Martin <martin.doerr at sap.com> wrote:
> >
> > Hi Volker,
> >
> > I think the 2 nested loops are not really needed.
> > If you use System.gc() + new String you should get it allocated at the desired location.
> > I believe this is sufficient with the flags you are using.
> >
> > The test seems to test interpreter, C1, and C2 with the loop limit of 30_000. I like that.
> >
> > The C1 fix looks good.
> >
> > Thanks for finding and fixing this bug.
> >
> > Best regards,
> > Martin
> >
> >
> > -----Original Message-----
> > From: hotspot-compiler-dev <hotspot-compiler-dev-bounces at openjdk.java.net> On Behalf Of Florian Weimer
> > Sent: Dienstag, 19. März 2019 22:48
> > To: Volker Simonis <volker.simonis at gmail.com>
> > Cc: hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
> > Subject: Re: RFR(S): 8221083: [ppc64] Wrong oop compare in C1-generated code
> >
> > * Volker Simonis:
> >
> > > The regression test reproduces the issue by allocation an object at an
> > > address with the 32-bit least significant bits being zero and comperes
> > > it with another null object.
> >
> >   79         for (int i = 0; i < 10; i++) {
> >   80             System.gc();
> >   81             for (int j = 0; j < 1024; j++) {
> >   82                 s = new String("I'm not null!!!");
> >   83                 if (WB.getObjectAddress(s) == 0x700000000L) break;
> >   84             }
> >   85             if (WB.getObjectAddress(s) == 0x700000000L) {
> >   86                 System.out.println("Got object at address 0x700000000");
> >   87                 break;
> >   88             }
> >   89         }
> >
> > I think this could use a labeled loop, like this:
> >
> >         GC_TESTS: for (int i = 0; i < 10; i++) {
> >             System.gc();
> >             for (int j = 0; j < 1024; j++) {
> >                 s = new String("I'm not null!!!");
> >                 if (WB.getObjectAddress(s) == 0x700000000L) {
> >                     System.out.println("Got object at address 0x700000000");
> >                     break GC_TESTS;
> >                 }
> >             }
> >         }
> >
> > (Untested.)
> >
> > On the other hand, neither this version or yours properly detects when
> > s is *not* actually the object with the desired address, in which case
> > the test objective fails to materialize, I think.