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

[John Rose]

On Jan 10, 2020, at 6:48 PM, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> Yes. The XOR seems pointless with this approach, but some shifting
> might be good.

A single multiply mixes the bits of its inputs.  If one input is
“random” or “white” (50% 1’s irregularly spaced) then the output
will probably look similar.  The output bits are not equally mixed,
though:  The LSB depends only on two bits of the input, and the
MSB (barring rare carry-outs) depends mostly on two other bits
of the input.  But the middle bits depend on most of the input bits.

So, given the goal of making a very simple, good-enough mixing
expression to get a 32-bit salt, this one is relatively good:

   long COLOR = 0x243F_6A88_85A3_08D3L;  // pi slice
   long SEED = System.nanoTime();  // or command line value
   int SALT = (int)( (COLOR * SEED) >> 16 );  // avoid LSB and MSB

In the longer term, I think the JVM should provide salt values
both for itself and (a few) core libs., and should allow those values
to be (partially) configured from the command line.  (Crash dumps
should report the SEED values used for reproducing the error.)
Given such a facility, it would be reasonable to upgrade it to use
better quality entropy sources and hashing (maybe optionally
crypto-quality, though I have reservations about that).  That
would make the variable behaviors unpredictable in practice.
Except when they are intentionally configured to be predictable.
An algorithm like xxHash would be a good starting point; it’s
cheap and salty.

— John