On Jan 10, 2020, at 10:47 AM, Remi Forax <fo...@univ-mlv.fr> wrote:
> Seem to be a JIT bug to me,
> the fields of Set12 are declared final not @Stable (even if the field storing
> the instanceof of Set&2 itself is marked @Stable) so there is no reason not
> not let the constant folding happen.
It’s part of the contract of @Stable that default values (null) are not
inlined. The reason for this is that some @Stable variables are lazy,
and the JIT needs to avoid assuming that default values stay that
way forever.
So, Claes is right that the empty slots need filling with a non-default
(non-null) value.
I think I’d prefer to see the following filler value rather `this`:
private static final EMPTY = new Object();
It might make escape analysis more robust if we don’t have objects
randomly storing pointer to themselves.
That value `SALT >= 0` inverts regularly every four seconds,
doesn’t it? Not very salty, that. I suggest adding a multiply to
make that sign bit more spicy:
long nt = System.nanoTime();
nt *= 0x243F_6A88_85A3_08D3L; // a slice of pi
SALT = (int)((nt >>> 32) ^ nt);
REVERSE = SALT >= 0;
The hex number is the fractional part of pi (in hex).
Any arbitrary odd number with a balance of 1’s and 0’s will mix
things up well enough to produce an irregularly varying sign bit.
Using a well-known number makes it obvious there’s nothing
up our sleeve.
— John
P.S. Not for this change set, but such salty values should be
derived from an optionally specified seed value, so JVM executions
can be made reproducible. Could be a diagnostic flag:
java -XX:+UnlockDiagnosticVMOptions -XX:VMSaltSeed=42
The salt seed would be initialized from the nanotime or some such.
