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
8255019: Shenandoah: Split STW and concurrent mark into separate classes #1009
Conversation
👋 Welcome back zgu! A progress list of the required criteria for merging this PR into |
@zhengyu123 The following labels 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 lists. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
|
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.
Overall a great refactoring!
I wonder if we should keep marking state in a single class e.g. ShenandoahMarkingState or even just add it to ShenandoahMarkingContext, instead of scattering it over ShenandoahHeap?
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.
Good work! I have a few questions...
@zhengyu123 this pull request can not be integrated into git checkout JDK-8255019-sh-mark
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 |
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.
First read review follows.
src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp
Outdated
Show resolved
Hide resolved
if (point == _degenerated_mark) { | ||
finish_mark(); | ||
} |
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.
So if we don't call finish_mark
, do we ever call set_concurrent_mark_in_progress(false);
and mark_complete_marking_context();
?
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 was not answered, and I don't see relevant follow-up changes. Is this a bug?
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.
No, I don't think so.
For fall through case, STWMark sets both flags.
For degen case, if we pass _degnerated_mark point, op_final_mark calls finish_mark to set them.
@shade, did I address all your concerns? Thanks. |
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.
All right, fine, let's do it.
/integrate |
@zhengyu123 Since your change was applied there have been 7 commits pushed to the
Your commit was automatically rebased without conflicts. Pushed as commit da6bcf9. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
This is the first part of refactoring, that aims to isolate three Shenandoah GC modes (concurrent, degenerated and full gc).
Shenandoah started with two GC modes, concurrent and full gc, with minimal shared code, mainly in mark phase. After introducing degenerated GC, it shared quite large portion of code with concurrent GC, with the concept that degenerated GC can simply pick up remaining work of concurrent GC in STW mode.
It was not a big problem at that time, since concurrent GC also processed roots STW. Since Shenandoah gradually moved root processing into concurrent phase, code started to diverge, that made code hard to reason and maintain.
First step, I would like to split STW and concurrent mark, so that:
The patch mainly just shuffles code. Creates a base class ShenandoahMark, and moved shared code (from current shenandoahConcurrentMark) into this base class. I did 'git mv shenandoahConcurrentMark.inline.hpp shenandoahMark.inline.hpp, but git does not seem to reflect that.
A few changes:
Progress
Issue
Reviewers
Download
$ git fetch https://git.openjdk.java.net/jdk pull/1009/head:pull/1009
$ git checkout pull/1009