Hi Ivan,
On 4/04/2018 10:01 AM, Ivan Gerasimov wrote:
Hi David!
On 4/3/18 4:49 PM, David Holmes wrote:
Hi Ivan,
On 4/04/2018 9:22 AM, Ivan Gerasimov wrote:
Hello!
Yet another occurrence of not-optimally pre-sized HashMap.
When java.lang.Class.enumConstantDirectory is created, the initial
capacity is set to be (2 * universe.length), which is more than
necessary in some cases.
Choosing the capacity optimally will allow us to save a few bytes
with some enum classes.
How are you defining optimal?
By optimal I meant the minimum value that will not make the internal
storage to be reallocated during insertion.
Here's a quotation from the documentation [1]:
"If the initial capacity is greater than the maximum number of entries
divided by the load factor, no rehash operations will ever occur."
Given the default load factor 0.75, the formula (expectedSize / 0.75 +
1) gives us the optimal initial capacity.
Isn't it simpler to just do:
new HashMap(universe.length, 1.0f);
and change the load factor? Otherwise you have to allow for an extra 25%
of space, and that is before it expands to be a power of 2 IIUC.
David
The testlibrary class testlibrary/OptimalCapacity.java is used to make
sure that the chosen initial capacity is neither too low (so that no
reallocations happen) nor too high (no memory is wasted).
With kind regards,
Ivan
[1] https://docs.oracle.com/javase/10/docs/api/java/util/HashMap.html
The bug report only gives one example where the current calculation
produces a too large value. If the HashMap itself rounds up the
initial capacity to a power of 2, how much extra space do we need
compared to universe.length? Do we just need to pass
(universe.length+1) to get the smallest power of 2 greater than
universe.length?
Thanks,
David
Would you please help review this trivial fix?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200696
WEBREV: http://cr.openjdk.java.net/~igerasim/8200696/00/webrev/