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
