RFR: 8201650: Move iteration order randomization of unmodifiable Set and Map to iterators

[Stuart Marks]

On 4/18/18 8:20 AM, Claes Redestad wrote:
> please review this change that moves the use of SALT to iterator creation, which 
> would allow for certain startup
> optimizations in the future.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201650
> Webrev: http://cr.openjdk.java.net/~redestad/8201650/open.00/
> 
> This does make the randomness of iteration order weaker as we're only 
> randomizing the starting point (varying with
> the size of the collection) and the iteration direction (run-to-run variant; 
> weaker than calculating per size, but
> allows this patch to be performance neutral).
> 
> Some Set/Map operations become very slightly faster with this patch, but that's 
> in the noise. Iterator operations
> remain largely performance neutral, sometimes even a bit faster.

Hi Claes,

I finally got a chance to look at this. Overall looks fine. Although the 
randomness is "weaker" iterating in both directions will, I think, still have 
the desired effect of flushing out order dependencies.

I have a test (forthcoming) that verifies that iteration order will vary from 
run to run, and it passes with both the old and new code.

Not an issue, but I'm curious as to why the initial index is chosen this way:

     idx = Math.floorMod(SALT ^ remaining, elements.length);

The floorMod with a divisor of elements.length makes perfect sense. I'm 
wondering why the dividend is (SALT ^ remaining) and not just SALT for example.

Thanks,

s'marks