-
Notifications
You must be signed in to change notification settings - Fork 16
[22.3] Allow built-in periodic JFR events when using JFR API to make recordings #574
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
[22.3] Allow built-in periodic JFR events when using JFR API to make recordings #574
Conversation
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 and safe to backport.
@roberttoyonaga do you think it would be possible to backport the TestThreadCPULoadEvent test as well?
Nit: Ideally you should use git cherry-pick -x for backporting. This will preserve the same commit message and set of commits, while also adding a reference to the commit SHA you are cherry-picking/backporting, which makes tracking things a bit easier.
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.
Please pin the CI to commit 5c44969947cbeff84ca9ccedc127cb6730b82415 as with the 23.0 backport so as to get cleaner CI runs. Thanks!
I believe we should adapt |
If you think that's worth it... |
It won't be trivial but it will allow us to keep testing arbitrary configurations on demand, I am afraid that if we pin it to a specific version then at some point that specific version might require some patching and then we will need to a new branch and maintain it. Depending on how hard it turns out to be I might change my mind :) |
|
@roberttoyonaga now that #577 is merged could you please change the build type in the mandrel.yml workflow to You can do so by adding the following line below |
Summary
Built-in periodic JFR events were previously erroneously disabled unless JFR is started from the command line when executing your app. This means that users using the JFR API would not have access to those periodic events. The fix is to always register the built-in periodic events if JFR is in the image, regardless of whether a recording is started upon application execution.
Original fix: oracle#7252