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
8275056: Virtualize G1CardSet containers over heap region #6059
8275056: Virtualize G1CardSet containers over heap region #6059
Conversation
|
Webrevs
|
@tschatzl this pull request can not be integrated into git checkout submit/8275056-virtualize-g1cardset-containers2
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push |
@tschatzl 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 78 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.
|
…nfiguration, so move it to the correct constructor
Reran tier1-5 without issues (except assert problem that has been fixed in bdf9950). |
After some discussion with @kstefanj we thought it would be best to limit the ergonomics to 32M regions (the previous maximum) since the choice of heap region size affects several other internal tuning (chunk sizing for scanning remembered sets, parallelism). Their impact has not been explored too much. The user may still manually select larger sizes up to 512M at the moment, assuming that if you override the defaults, we assume that you will measure the impact appropriately. Of course, feedback by users about their choice is appreciated. |
With the change for JDK-8276548 / PR#6230 now in (I merged it for your convenience), this change works now :) There has been no change in this PR, but the processing of "Full" cards has been wrong with region virtualization. |
void do_cardsetptr(uint region_idx, size_t num_occupied, G1CardSet::CardSetPtr card_set) override { | ||
CardOrRanges<Closure> cl(_iter, | ||
region_idx >> _log_card_regions_per_region, | ||
(region_idx & _card_regions_per_region_mask) << _log_card_region_size); | ||
_card_set->iterate_cards_or_ranges_in_container(card_set, cl); |
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.
region_idx
is actually card_region_idx
, right? If so, card_region_idx >> _log_card_regions_per_region
==> region_idx
(the second arg of G1ContainerCardsOrRanges
constructor) makes sense to me.
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, that is the unchanged "region" that the hash table for the containers sees, which is the card_region_idx
at this level.
(uint)HeapRegion::CardsPerRegion, /* max_cards_in_cardset */ | ||
default_log2_card_region_per_region()) /* log2_card_region_per_region */ | ||
{ | ||
assert((_log2_card_region_per_heap_region + _log2_card_region_size) == (uint)HeapRegion::LogCardsPerRegion, |
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.
I suggest _log2_card_region_size -> _log2_cards_per_card_region
; then the assertion becomes more consistent, IMO.
assert((_log2_card_region_per_heap_region + _log2_cards_per_card_region) == (uint)HeapRegion::LogCardsPerRegion)
, which, in math form, is
(card_region / heap_region) x (cards / card_region) == cards / (heap_)region
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.
Implemented. I'll push in around 7-8 hours unless somebody objects.
Thanks @albertnetymk @kstefanj for your reviews. /integrate |
Going to push as commit 1830b8d.
Your commit was automatically rebased without conflicts. |
Hi all,
can I have reviews for this change that virtualizes
G1CardSet
"regions" over a heap region, allowing the use of multiple "G1CardSet
card regions" across a single heap region?I.e.
HeapRegionRemSet
, which is the interface to a region's card set, simply uses multiple indexes for the remembered set of a single source heap region if necessary. E.g. on a 128MB region, heap region 0's cards would be stored as (what I call) "card region" indexes 0..3 as appropriate in its_card_set
.When retrieving the values, the appropriate retransformation is done (during
HeapRegionRemSet::iterate_for_merge()
).Assigning
HeapRegionRemSet
to handle all this multiplexing required some move of theG1CardSet::iterate_for_merge
method toHeapRegionRemSet
, which is why there are more changes than expected.One change I would like to have opinions on is storing the amount of card regions per region into
G1CardSetConfiguration
, maybe it is better to put this intoHeapRegionRemSet
- but I did not want to start aHeapRegionRemSetConfiguration
(maybe also put the cached values introduced in thesplit_card
optimization there as well?).This allows unlimited actual heap region size. Currently set to 512MB (what we would set ergonomically if on a 1 TB heap), but that's just a random number basically.
Feel free to suggest a different maximum heap region size if any. We could also keep the ergonomics use a smaller heap region size (e.g. 32M as before).
There is also a CSR to look at.
Testing: tier1-5, some perf testing on region sizes up to 512M with slight improvements in specjbb2015 with larger region sizes.
Thanks,
Thomas
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/6059/head:pull/6059
$ git checkout pull/6059
Update a local copy of the PR:
$ git checkout pull/6059
$ git pull https://git.openjdk.java.net/jdk pull/6059/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 6059
View PR using the GUI difftool:
$ git pr show -t 6059
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/6059.diff