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

[XenoAmess]

On Fri, 11 Mar 2022 19:40:39 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> I think we can rely on the monotonicity of these functions. If populating a map both with 49 and with 96 mappings results in a table length of 128, we don't need to test that all the intermediate inputs also result in a table length of 128. Including all the intermediate inputs makes the source code more bulky and requires future readers/maintainers to hunt around in the long list of tests to figure out which ones are significant. Really, the only ones that are significant are the boundary cases, so just keep those. Adding more tests that aren't relevant actually does hurt, even if they execute quickly. So: please cut out all the extra test cases that aren't near the boundary cases.

what I worried is, the boundary this is based on the current table size calculating mechanic in HashMap.

If people change the mechanic in HashMap, then the boundary would change.

But well, this is a white box text for HashMap (and HashMap-like) classes after all, so maybe I'm just over overthinking too much.

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

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