8264424: Support OopStorage bulk allocation #3264
Conversation
|
👋 Welcome back kbarrett! A progress list of the required criteria for merging this PR into |
|
@kimbarrett The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
| MutexLocker ml(_allocation_mutex, Mutex::_no_safepoint_check_flag); | ||
| block = block_for_allocation(); | ||
| if (block == NULL) return 0; // Block allocation failed. | ||
| // Take exclusive use of this block for allocation. |
There was a problem hiding this comment.
Maybe "Taking all remaining entries, so remove from list."? The "exclusive use" is ensured by the above MutexLocker, not unlink.
| // number of entries that will be allocated is never more than the minimum | ||
| // of size and bulk_allocate_limit, but may be less than either. Possibly |
There was a problem hiding this comment.
It took me a few seconds to understand this sentence. Maybe replace it with "postcondition: result <= min(size, bulk_allocate_limit)" below?
|
@kimbarrett This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be: You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been no new commits pushed to the ➡️ To integrate this PR with the above commit message to the |
|
Thanks for reviews @albertnetymk and @tschatzl |
openjdk
bot
added
integrated
|
@kimbarrett Pushed as commit 22b20f8. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Please review this change to OopStorage to support bulk allocation. A new overload for allocate is provided:
The approach taken is to claim all of the available entries in the first available block, add as many of those entries as will fit in the buffer, and release any remaining entries back to the block. Only the claim part needs to be done while holding the allocation mutex. This is is optimized for clients that want more than just a couple entries, and minimizes time under the lock. The maximum number of entries (the number of entries in a block) is provided as a constant for sizing requests, to avoid the release of unrequested entries. An application that wants more than that, or a specific number that might not be available from the next block, needs to make multiple bulk allocation calls, but that's still going to be much faster than one at a time allocations.
Testing:
mach5 tier1
New gtest for bulk allocation.
I've been using this for a while as part of another in-development change that makes heavy use of this feature.
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/3264/head:pull/3264$ git checkout pull/3264Update a local copy of the PR:
$ git checkout pull/3264$ git pull https://git.openjdk.java.net/jdk pull/3264/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 3264View PR using the GUI difftool:
$ git pr show -t 3264Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/3264.diff