-
Notifications
You must be signed in to change notification settings - Fork 10.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sync bugfix in JDK 8281631, about HashMap allocation capacity. #5965
Conversation
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). For more information, open the CLA check for this pull request. |
Thanks for taking the trouble to look into this! I'm not sure we want to make this change, or at least not unconditionally. In the short to mid term, people will be running this code on JDK versions that don't have your change. So then Perhaps we could check |
I wrote a test for you to make it clearer. You can run the test I provided at the original version without my changes to Maps, on a jdk8, to see how it fails and why I want to fix it here.
Actually not. Look at your original codes there, they are using the calculation in HashMap.putAll, which is buggy. But the resize in openjdk is good. we only fixed the calculation in HashMap.putAl in 8281631. So I think it should be fixed here too, as the former false calculation are from HashMap.putAl. But the resize function is good, so it will not invoke a resize. |
Thanks for the detailed explanation and the test! Here's my understanding now. Let's look at one of the problematic sizes, like 12. Currently, With the change here, The important thing I missed was the delayed allocation of Because of the way syncing with our internal source-code management system works, we won't be merging this PR, but we'll make equivalent changes, duly credited. Thanks again! |
[This JDK change](openjdk/jdk@3e39304) fixed the computation used when the first write to a `HashMap` is `putAll(otherMap)`. Previously that would occasionally lead to an unnecessarily large internal table. That same computation was copied into `Maps.newHashMapWithExpectedSize`, so it should also be adjusted. Thanks to @XenoAmess for both the JDK fix and the fix here. Closes #5965. RELNOTES=`Maps.newHashMapWithExpectedSize` sometimes allocated maps that were larger than they needed to be. PiperOrigin-RevId: 436318398
[This JDK change](openjdk/jdk@3e39304) fixed the computation used when the first write to a `HashMap` is `putAll(otherMap)`. Previously that would occasionally lead to an unnecessarily large internal table. That same computation was copied into `Maps.newHashMapWithExpectedSize`, so it should also be adjusted. Thanks to @XenoAmess for both the JDK fix and the fix here. Closes #5965. RELNOTES=`Maps.newHashMapWithExpectedSize` sometimes allocated maps that were larger than they needed to be. PiperOrigin-RevId: 436318398
see openjdk/jdk@3e39304