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.redes...@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.redes...@oracle.com
>> <mailto:claes.redes...@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
