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
8255234: ZGC: Bulk allocate forwarding data structures #804
Conversation
|
/contributor add ayang |
@pliden |
/contributor add pliden |
@pliden |
Webrevs
|
ZForwarding::destroy(_forwardings[i]); | ||
_forwardings[i] = NULL; | ||
} | ||
_nforwardings = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not needed, right? _nforwardings
will be properly reset in populate
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is strictly not needed. But even if the backing memory is still there, the relocation set is conceptually reset here. For example, RelocationSetIterator should not return any forwardings after this point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True; the set is conceptually empty after this.
if (new_top > _end) { | ||
// Not enough space left | ||
return NULL; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This allocator should never return null; better use assert.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, good point. Will fix.
} | ||
|
||
// Update statistics | ||
ZStatRelocation::set_at_populate_relocation_set(_allocator.size()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of _allocator.size()
, one could use the same arg of _allocator.reset()
, which is already known in this scope.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I can change that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, the size()
function will still be needed in the follow up patch #805, where the size isn't calculated in the same score. So in the end I think it's easier to just keep it here too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK.
ZForwarding::destroy(_forwardings[i]); | ||
_forwardings[i] = NULL; | ||
} | ||
_nforwardings = 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True; the set is conceptually empty after this.
} | ||
|
||
// Update statistics | ||
ZStatRelocation::set_at_populate_relocation_set(_allocator.size()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK.
Looks good. Thanks for accepting the proposed changes. (Some old comments might have been sent by the mlbridge. I've delete those in the PR)
@pliden This change now passes all automated pre-integration checks. 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 79 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.
|
/integrate |
@pliden Since your change was applied there have been 79 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit 2c9dfc7. |
Allocation of forwarding data structures (ZForwarding/ZForwardingEntry instances) can generate a lot of calls to new/malloc if the number of pages in the relocation set is large. This can make the "Concurrent Select Relocation Set" phase long. By bulk allocating a single piece of memory and then placement new() all objects into that memory we can speed this phase up quite a bit.
During relocation set selection we keep track of the number of ZForwardingEntry instances we will need for the selected relocation set. The ZForwardingAllocator is then initialized to have enough room for all the relocation set array, all ZForwarding instances, and all ZForwardingEntry instances. Objects are then placement new()'d using into the memory allocated by the ZForwardingAllocator.
This patch was joint work with Albert (ayang).
Progress
Issue
Reviewers
Contributors
<ayang@openjdk.org>
<pliden@openjdk.org>
Download
$ git fetch https://git.openjdk.java.net/jdk pull/804/head:pull/804
$ git checkout pull/804