Maintenance Notice

The bugs.java.com site will be undergoing maintenance on 15th Dec 2017 21:00 PST to 16th Dec 2017 1:00 AM PST.
JDK-8006593 : Initialization bottleneck in Maps due to use of j.u.Random
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:collections
  • Affected Version: 7u6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-01-18
  • Updated: 2013-08-27
  • Resolved: 2013-03-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availabitlity Release.

To download the current JDK release, click here.
JDK 7
7u40 b18Fixed
Description
The alternative hashing introduced in 7u6 includes a feature to randomize the layout of individual map instances. This is accomplished by generating a random mask value per hash map. The initialization of this field is introduces a bottleneck because it uses a shared random number generator, java.util.Random
Comments
I've added 8-na on the assumption that nothing needs to be forward-ported (it's all mute with Brent work on HashMap anyway).
2013-05-11

Updated webrev. Hashtable implementation is similar to HashMap
2013-02-22

The solution used is to use a ThreadLocalRandom instead of a shared Random instance. The one concern I have with this approach is that we have no control over seeding for TLR and that this may be somehow exploitable. I've also included a test patch which reverts Hashtable back to it's original pre-7u6 state. We can debate whether to include this as part of the update for 7u6. If we opt not to revert Hashtable then the changes are similar to what was done for HashMap. LinkedHashMap, WeakHashMap and ConcurrentHashMap are unchanged by this patch but will benefit from the removal of the bottleneck in un.misc.Hashing.randomHashSeed()
2013-02-09

Initial suggestion it to replace use of java.util.Random SEED_MAKER in sun.misc.Hashing.Holder with ThreadLocalRandom
2013-01-18

See original report on StackOverflow: http://stackoverflow.com/questions/14010906/given-that-hashmaps-in-jdk1-6-and-above-cause-problems-with-multi-threading-how and original discussion on corelibs-dev: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-January/013329.html
2013-01-18