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

[Claes Redestad]

Hi,

On 2020-01-11 02:23, John Rose wrote:
> On Jan 10, 2020, at 10:47 AM, Remi Forax <forax at univ-mlv.fr 
> <mailto: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.

this was actually what I did in my first stab at this. :-) Also why I
needed to fiddle with the archiving state: the EMPTY marker needs to be
archived to retain identity (this is why we need to archive the
EMPTY_MAP/SET/.., too).

Stuart suggested the 'this' approach, which seemed to perform just as
well in microbenchmarks. You're probably right in your suspicion that it
might interact subtly with EA in more complex scenarios, so going back
to an EMPTY marker object might be the safer route here.

> 
> 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.

Yes. The XOR seems pointless with this approach, but some shifting
might be good.

> 
> — 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.

This'd be useful in some cases.

/Claes