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

[Claes Redestad]

Hi,

I included John's suggested salt improvement, reverted to use an
EMPTY object marker rather than 'this', and removed the
extraneous blank line Roger pointed out:

http://cr.openjdk.java.net/~redestad/8236850/open.01/

/Claes

On 2020-01-11 04:19, John Rose wrote:
> On Jan 10, 2020, at 6:48 PM, Claes Redestad <claes.redestad at oracle.com 
> <mailto: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