-
Notifications
You must be signed in to change notification settings - Fork 6.2k
8346082: Output JVMTI agent information in hserr files #22706
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 39 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
|
|
/label add sereviceability |
|
/label add serviceability |
|
@dholmes-ora
|
|
@dholmes-ora |
dholmes-ora
left a comment
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.
Seems okay. Someone from serviceability should give their opinion on the content.
|
I do not understand the use case that this additional information solves for, nor does the bug provide any further enlightenment, I think this ER requires more rationale to motivate its inclusion. |
Currently the info about the JVMTI agents in the hserr/hsinfo is not good. You might see them in the so/dll list and maybe command-line output but this is far from ideal. A little separate section gives more clarity. |
TheRealMDoerr
left a comment
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.
Nice enhancement! Could you add an example output to the description, please?
tstuefe
left a comment
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.
Looks fine, two bikeshedding nits.
I approve now, up to you if you take my suggestions.
src/hotspot/share/runtime/os.cpp
Outdated
| const char* instrumentinfo = agent->is_instrument_lib() ? "instrumentlib" : ""; | ||
| const char* loadinfo = agent->is_loaded() ? "loaded" : "not loaded"; | ||
| const char* initinfo = agent->is_initialized() ? "initialized" : "not initialized"; |
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 would just print these as flags, its clearer and simpler to print. E.g.
"myagent path: mylib.so dynamic:1 loaded:1 instrument_lib:0 initialized:1 xxx options xxx"
src/hotspot/share/runtime/os.cpp
Outdated
| while (it.has_next()) { | ||
| const JvmtiAgent* agent = it.next(); | ||
| if (agent != nullptr) { | ||
| if (first_agent) st->print_cr("JVMTI agents:"); |
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.
if no agents are loaded, I would print "JVMTI agents: none" unconditionally. Makes it more obvious than just a missing entry; that could be also an error.
Currently it looks like this (example is from a JVM started with async-profiler : |
Maybe after the while loop something like this ? |
You can do it before the loop: and get rid of |
|
When printing 'JVMTI agents: none' , should I maybe better iterate |
TheRealMDoerr
left a comment
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.
|
Hi Martin, David, Thomas, thanks for the reviews ! (should we consider adding the JVMTI agent output to jcmd too as a separate command/option? (but not in this change) ) |
|
Mailing list message from Laurence Cable on serviceability-dev: again what's the use case? On 12/16/24 6:35 AM, Matthias Baesken wrote: |
Assume a customer uses a tool like the async profiler and causes a JVM crash by doing that. A supporter looks at the hs_err file and wonders about what might have happened. Such a hint would be very helpful. |
|
Mailing list message from Laurence Cable on serviceability-dev: On 12/16/24 8:45 AM, Martin Doerr wrote:
I was referring to the suggestion that there should be a jcmd to emit |
Okay, then let's avoid adding it to jcmd; for hserr/hsinfo adding the info is more important. My idea was that currently we can do 'data dump' and 'load agents' with jcmd So for completeness, when you offer loading agents, it might be useful to be able to show the current agents with the same tool jcmd. But on the other hand you are probably correct that this new option might not be used a lot so it is maybe not worth the effort. |
|
/integrate |
|
Going to push as commit c75b1d4.
Your commit was automatically rebased without conflicts. |
Since we already have VM.info jcmd, which after your patch already shows jvmti info, a separate command would be redundant, no? |
We should output more information about the JVMTI agents in the hserr file.
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/22706/head:pull/22706$ git checkout pull/22706Update a local copy of the PR:
$ git checkout pull/22706$ git pull https://git.openjdk.org/jdk.git pull/22706/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 22706View PR using the GUI difftool:
$ git pr show -t 22706Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/22706.diff
Using Webrev
Link to Webrev Comment