RFR: 8236850: Operations on constant List/Set.of(element) instances does not consistently constant fold

[John Rose]

On Jan 10, 2020, at 10:47 AM, Remi Forax <forax at 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.