-
Bug
-
Resolution: Fixed
-
P4
-
None
Some utility methods in test/lib/jdk/test/lib/util/OptimalCapacity.java attempt to check that various collections such as HashMap have been allocated with the optimal capacity.
These utilities are used by these tests:
test/jdk/java/lang/Character/UnicodeBlock/OptimalMapSize.java
test/jdk/java/lang/Enum/ConstantDirectoryOptimalCapacity.java
There is a problem with the assertions in OptimalCapacity.ofHashMap. This utility method takes an map that has been populated by some code under test and compares its table size to that of (1) a HashMap created with a copy constructor, and (2) a HashMap created with an initial expected size. If these sizes differ, the utility reports an error.
Populating a map using a copy constructor from a map with N mappings has a bug; seeJDK-8281631. In addition, the expression used to allocate the enum directory has a similar bug, so this test passed for a long time. When we fixed JDK-8281631, it broke this test. (This test was problem-listed as part of JDK-8281631.)
The OptimalCapacity utilities are really more of a test of HashMap. And the Enum/ConstantDirectoryOptimalCapacity test replicates the map capacity computation (int)(n / 0.75f) + 1 from the creation code in java/lang/Class.java in the test itself, so isn't really testing anything.
I haven't inspected the UnicodeBlock optimal map size test thoroughly but it seems suspicious as well.
At the very least, these tests and the utility class should be cleaned up. I'm not sure how much value they provide, so maybe they should be removed entirely.
These utilities are used by these tests:
test/jdk/java/lang/Character/UnicodeBlock/OptimalMapSize.java
test/jdk/java/lang/Enum/ConstantDirectoryOptimalCapacity.java
There is a problem with the assertions in OptimalCapacity.ofHashMap. This utility method takes an map that has been populated by some code under test and compares its table size to that of (1) a HashMap created with a copy constructor, and (2) a HashMap created with an initial expected size. If these sizes differ, the utility reports an error.
Populating a map using a copy constructor from a map with N mappings has a bug; see
The OptimalCapacity utilities are really more of a test of HashMap. And the Enum/ConstantDirectoryOptimalCapacity test replicates the map capacity computation (int)(n / 0.75f) + 1 from the creation code in java/lang/Class.java in the test itself, so isn't really testing anything.
I haven't inspected the UnicodeBlock optimal map size test thoroughly but it seems suspicious as well.
At the very least, these tests and the utility class should be cleaned up. I'm not sure how much value they provide, so maybe they should be removed entirely.
- relates to
-
JDK-8281631 HashMap copy constructor and putAll can over-allocate table
- Closed
-
JDK-8283465 Character.UnicodeBlock.NUM_ENTITIES is out of date
- Resolved
-
JDK-8186958 Need method to create pre-sized HashMap
- Resolved