RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v22]

[XenoAmess]

On Sun, 20 Feb 2022 19:11:26 GMT, liach <duke at openjdk.java.net> wrote:

> > I don't thik it reasonable. or is there eveidence it be?
> 
> If this map is too dense, there may be a lot of hash collisions, and the lookup performance would decrease because this hashmap is linear probe than red-black tree buckets like the regular hash map is using. This was effectively trading some memory for better performance. You should run benchmarks to see how bad the lookup performance degrades after you saves memory used by the hash table.

@liach

1. `* 1.1` don't seem a very reasonable number for making it non-dense
2. the main reason I argue about is it does not make the resize at `put` and the `map constructor` follow a same resize way.

you create an IdentityHashMap `mapA`, put 19 key-value pairs, and build another IdentityHashMap using `mapB = new IdentityHashMap(mapA)`, and you can find mapB's table is twice larger than mapA's.
That seems weird and nonsence.
I can accept it if mapB's table's length is smaller or equal than mapA, but larger...why need to make it larger when we copy a map?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7431