On Jan 10, 2020, at 6:48 PM, Claes Redestad <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
