RFR: 8322149: ConcurrentHashMap copy constructor should not transfer from old table on presizing [v2]

[Joshua Cao]

On Mon, 8 Jan 2024 15:59:17 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Shouldn't this be something like tryPresize(this.size() + m.size()) to accommodate for the worst case where there are no common keys in this map and m?

Its a good callout. Not sure if it is a miss, or intentionally conservative.

> But then shouldn't we use at least max(this.size(), m.size)?

We don't need to compute `max()` here. [tryPresize()](https://github.com/openjdk/jdk/blob/8a4dc79e1a40e7115e2971af81623b6b0368f41c/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java#L2397) does that already. Although this does bring to my attention that maybe there is the same symptom of "extra unnecessary work" when merging in a smaller map. If the new size is smaller, we should just be able to exit out of `tryPresize()` without having to call the expensive `transfer()`. We would need to run a separate experiment for it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17116#discussion_r1445292956