RFR(S): 8221083: [ppc64] Wrong oop compare in C1-generated code
Doerr, Martin
martin.doerr at sap.com
Wed Mar 20 11:24:17 UTC 2019
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.
More information about the hotspot-compiler-dev
mailing list