United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-8006593 : Initialization bottleneck in Maps due to use of j.u.Random

Details
Type:
Bug
Submit Date:
2013-01-18
Status:
Closed
Updated Date:
2013-08-27
Project Name:
JDK
Resolved Date:
2013-03-12
Component:
core-libs
OS:
Sub-Component:
java.util:collections
CPU:
Priority:
P3
Resolution:
Fixed
Affected Versions:
7u6
Fixed Versions:
7u40 (b18)

Related Reports
Backport:

Sub Tasks

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
URL:   http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/b03bbdef3a88
User:  lana
Date:  2013-03-26 01:06:21 +0000

                                     
2013-03-26
URL:   http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/b03bbdef3a88
User:  mduigou
Date:  2013-03-12 17:30:40 +0000

                                     
2013-03-12
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
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
Initial suggestion it to replace use of java.util.Random SEED_MAKER in sun.misc.Hashing.Holder with ThreadLocalRandom 
                                     
2013-01-18



Hardware and Software, Engineered to Work Together