-
Notifications
You must be signed in to change notification settings - Fork 6.2k
8350106: [PPC] Avoid ticks_unknown_not_Java AsyncGetCallTrace() if JavaFrameAnchor::_last_Java_pc not set #23640
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 rrich! A progress list of the required criteria for merging this PR into |
|
@reinrich 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 6 new commits pushed to the
Please see this link for an up-to-date comparison between the source branch of this pull request and the ➡️ To integrate this PR with the above commit message to the |
190911d to
9d3aa98
Compare
9d3aa98 to
768bfcb
Compare
Webrevs
|
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 to get more samples! LGTM.
|
Test failure on aarch64 is unrelated. |
|
Going to push as commit 030c85d.
Your commit was automatically rebased without conflicts. |
|
Apparently causes #24216, take a look? |
This pr changes
JavaThread::pd_get_top_frame_for_profilingto better address situations whereJavaThread::last_Java_sp()returns != nullJavaThread::last_Java_pc()returns nullIf the runtime needs to walk the stack of a java thread in that state, e.g. for gc purposes, it finds the last java pc relative to the last java sp (see frame::setup()).
This relies on the runtime method being called to store the return pc to its caller's abi which it will do when pushing a new frame for calling another method.
For an asynchronous interrupt to sample the stack this means: if there isn't at least one frame between the last java frame and the frame where the interrupt occurred then we can't be sure that the return pc was already saved and
pd_get_top_frame_for_profiling()needs to return false indicating failure.Otherwise we can and should proceed constructing a frame even though
JavaThread::last_Java_pc()returned null.Testing:
Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/23640/head:pull/23640$ git checkout pull/23640Update a local copy of the PR:
$ git checkout pull/23640$ git pull https://git.openjdk.org/jdk.git pull/23640/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 23640View PR using the GUI difftool:
$ git pr show -t 23640Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/23640.diff
Using Webrev
Link to Webrev Comment