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
8270014: Add scoped objects for g1 young gc verification and young gc internal timing #4768
8270014: Add scoped objects for g1 young gc verification and young gc internal timing #4768
Conversation
|
Webrevs
|
@@ -519,8 +519,6 @@ void G1GCPhaseTimes::print_other(double accounted_ms) const { | |||
} | |||
|
|||
void G1GCPhaseTimes::print() { | |||
note_gc_end(); | |||
|
|||
if (_cur_verify_before_time_ms > 0.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.
Is this if
just checking whether verification is enabled or not? If so, can VerifyBeforeGC
be used? Otherwise, it's unclear to me why we are comparing it with 0.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.
The if
checks whether any verification work has been done (it will be > 0.0 if it has been set) in this pause. We can't just use VerifyBefore/AfterGC
because verification before/after does not always run for all young gc pauses (see VerifyGCType
).
If we want to change this (existing) behavior to like always print the time if the flag is enabled I would suggest to file another CR instead of hiding it here (I can do all that and the associated work if that is desired).
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.
We can't just use VerifyBefore/AfterGC because...
I see; thank you for the explanation.
If we want to change this (existing) behavior to like always print the time if the flag is enabled
Either that or just put some comment there, since in what situation the condition is true is not obvious. Ofc, this is very subjective.
src/hotspot/share/gc/g1/g1Policy.hpp
Outdated
void note_young_gc_pause_start(); | ||
void note_young_gc_pause_end(); |
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.
It's not obvious to me if there's a diff btw young_gc_pause
and young_collection
, or what the diff is. I think having some comments for these two pairs of methods would make it easier to understand.
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.
Added comments. gc_pause
is the whole pause, collection
is about just the collection part (as defined by the inner scope of the do_collection_pause_at_safepoint_helper
). Feel free to suggest better naming.
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.
Maybe something like record_young_collection_work_start
; another question is whether we should keep the note_
prefix for the pause or change it to record_
as well as it seems quite common.
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 we change to record_
src/hotspot/share/gc/g1/g1Policy.cpp
Outdated
G1GCPhaseTimes* p = phase_times(); | ||
|
||
double end_time_sec = os::elapsedTime(); | ||
double start_time_sec = phase_times()->cur_collection_start_sec(); | ||
double start_time_s = phase_times()->cur_collection_start_sec(); |
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 dislike this change of nomenclature to use _s
suffix instead of _sec
suffix to indicate units of seconds. The latter is in wide use in GC code.
@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 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.
|
Thanks @albertnetymk @walulyai @kimbarrett for your reviews. /integrate |
Going to push as commit 7a89ffe.
Your commit was automatically rebased without conflicts. |
Hi all,
can I get reviews for some further cleanup of the young collection code:
Thanks,
Thomas
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/4768/head:pull/4768
$ git checkout pull/4768
Update a local copy of the PR:
$ git checkout pull/4768
$ git pull https://git.openjdk.java.net/jdk pull/4768/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 4768
View PR using the GUI difftool:
$ git pr show -t 4768
Using diff file
Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/4768.diff