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

[Paul Sandoz]

Looks good.

  78     private static final Object[] EMPTY;

Is there a specific reason related to archiving that this is Object[] and not Object and instead assigned a value of new Object() ?

--

For information purposes: an alternative salt might be to use mix32 from Splittable random:

/**
 * Returns the 32 high bits of Stafford variant 4 mix64 function as int.
 */
private static int mix32(long z) {
    z = (z ^ (z >>> 33)) * 0x62a9d9ed799705f5L;
    return (int)(((z ^ (z >>> 28)) * 0xcb24d0a5c88c35b3L) >>> 32);
}

as in:

SALT = mix32(System.nanoTime());

Paul.

> On Jan 13, 2020, at 6:48 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> 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