Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
8252752: Clear card table for old regions during scan in G1 #343
can I get reviews for this change that removes the need for explicit clearing of the card table for typically a large amount of regions in most cases?
Currently g1 unconditionally marks scanned dirty cards as "scanned" to remember that they had already been scanned in earlier evacuation passes. Then in the "clear card table phase" g1 clears all these marks including the card table of evacuated regions.
This change modifies g1 so that if possible, it clears dirty cards after scanning them instead of setting them to "scanned" if there is only one evacuation pass. This saves a lot of work later (e.g. the amount of regions to clear in the clear card table phase may be reduced by a magnitude or more, depending on the ration between evacuated and scanned regions).
The main change here is which type of regions (ones in the collection set, ones that are only scanned) are put into which list of regions g1 already manages: there is one "all" list containing all regions that need clearing, and a "next" list containing the regions to be scanned in the current evacuation pass. Previously g1 put regions into at least one list; now regions in the current collection set are always directly put into the "all" list (as they independently of other reasons require card table cleaning), while to-be-scanned regions are always only put into the "next" list.
Then, to achieve the desired effect that only regions that absolutely require clearing are in the "all" list, g1 does not merge the "next" list into the "all" list when it detects that there will only be one evacuation pass.
@tschatzl 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
kimbarrett left a comment
I found confusing the name may_do_optional_evacuation, used in various
"may do" to me suggests "permitted". I think better might be something like
Other than that naming issue, this looks good.
@tschatzl This change now passes all automated pre-integration checks.
After integration, the commit message for the final commit will be:
At the time when this comment was updated there had been 34 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.
@tschatzl Since your change was applied there have been 34 commits pushed to the
Your commit was automatically rebased without conflicts.
Pushed as commit e9c1782.