RFR 8200696 : Optimal initial capacity of java.lang.Class.enumConstantDirectory
ivan.gerasimov at oracle.com
Wed Apr 4 03:06:56 UTC 2018
On 4/3/18 6:41 PM, David Holmes wrote:
> 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:
>>>> 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 :
>> "If the initial capacity is greater than the maximum number of
>> entries divided by the load factor, no rehash operations will ever
>> 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.
Yes, it would be simpler of course.
However, the chance of a collision will also increase then.
Especially in cases when the number of entries is close (but not greater
than) to a power of 2.
Not sure if it matters in this particular case, as the number of enum
values is likely to be relatively small, so the lookup will be fast anyway.
But I thought it would be better to keep the default load factor and
just set the initial capacity to the optimal value: minimum while not
causing reallocations during insertion.
With kind regards,
>> 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,
>>  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
>>>> 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/
With kind regards,
More information about the core-libs-dev