On Sun, 20 Feb 2022 19:11:26 GMT, liach <d...@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
