-
Notifications
You must be signed in to change notification settings - Fork 5.8k
8329605: hs errfile generic events - move memory protections and nmethod flushes to separate sections #18626
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
Conversation
👋 Welcome back mbaesken! A progress list of the required criteria for merging this PR into |
@MBaesken This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. 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 141 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. ➡️ To integrate this PR with the above commit message to the |
Webrevs
|
We still have flooding in the frequent events. Instead of creating a common section for these vent, did you consider creating two new separate, specific sections for memory protection and nmethod flushing? |
I thought about creating new specific sections. Regarding those 2, maybe they are a bit too specific ? But on the other hand, if others like this idea, I am fine with it (creating sections for memory protection operations and for nmethod flushing). |
I asked around in my team and added a separate section for the nmethod flush operations. |
@@ -97,6 +99,8 @@ void Events::print() { | |||
void Events::init() { | |||
if (LogEvents) { | |||
_messages = new StringEventLog("Events", "events"); | |||
_nmethod_flush_messages = new StringEventLog("Nmethod flushs", "nmethodflushs"); |
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.
Should be "flushes" or "flushing events".
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.
LGTM - given the scope of this PR.
In general, I don't like the event log to be split into multiple streams being printed separately. Yes, separate sections prevent displacement of events by other, too verbose, events. On the other hand, time coherence is lost or has to be manually re-established by the support engineer. Often enough, an issue can only be understood when seeing multiple/all events in timely order.
Merging the event sections at print time by timestamp would be a helpful enhancement.
FWIW, I think I am of the opposite opinion. I find it very helpful to have the events separated into distinct sections and wouldn't want them all combined into one big section. |
Hi Lucy, thanks for the review ! May I have a second one please ?
Yeah, both approaches (one single big log, or multiple ones) have pros and cons. |
|
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 think it's ok if @stefank also likes it.
Hmm, I think the separation makes sense, but I don't like the "frequent" moniker. All other event logs are separated by thematic area. "frequent" is orthogonal to that. I can have frequent/non-frequent class loading messages, or exceptions. My proposal would be either to drop these memory protection events (do we need them? or are they remnants of some old support issues?) or to put them into a 'memprot' section or similar. |
I agree with @tstuefe |
A separate memprotect section would be good I can add this. |
I added a memprotect section. |
Hi Stefan, thanks for the review ! |
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, thank you
/integrate |
Going to push as commit 397d948.
Your commit was automatically rebased without conflicts. |
Currently the 'generic' hs_errfile Events message log (filled by Events::log) is sometimes rather full by messages for memory protection operations and nmethod flushes. Those seem to occur quite often and potentially move out other less frequent events, because the number of entries in the log is limited.
It might be better to separate the events into separate sections.
The mentioned memory protection operations related entries look like this :
Event: 0.178 Protecting memory [0x000000016ebf0000,0x000000016ebfc000] with protection modes 0
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/18626/head:pull/18626
$ git checkout pull/18626
Update a local copy of the PR:
$ git checkout pull/18626
$ git pull https://git.openjdk.org/jdk.git pull/18626/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 18626
View PR using the GUI difftool:
$ git pr show -t 18626
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/18626.diff
Webrev
Link to Webrev Comment