Skip to content

Conversation

@roberttoyonaga
Copy link
Collaborator

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

@oracle-contributor-agreement oracle-contributor-agreement bot added the OCA Verified All contributors have signed the Oracle Contributor Agreement. label Sep 18, 2023
@roberttoyonaga roberttoyonaga changed the title Allow built-in periodic JFR events when using JFR API to make recordings [23.0] Allow built-in periodic JFR events when using JFR API to make recordings Sep 18, 2023
@roberttoyonaga roberttoyonaga changed the title [23.0] Allow built-in periodic JFR events when using JFR API to make recordings [22.3] Allow built-in periodic JFR events when using JFR API to make recordings Sep 18, 2023
Copy link
Collaborator

@zakkak zakkak left a 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.

@zakkak zakkak requested a review from jerboaa September 19, 2023 06:37
Copy link
Collaborator

@jerboaa jerboaa left a 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!

@zakkak
Copy link
Collaborator

zakkak commented Sep 19, 2023

Please pin the CI to commit 5c44969947cbeff84ca9ccedc127cb6730b82415

I believe we should adapt default to make it work with 22.3 instead of pinning the version. I will have a look tomorrow.

@jerboaa
Copy link
Collaborator

jerboaa commented Sep 19, 2023

Please pin the CI to commit 5c44969947cbeff84ca9ccedc127cb6730b82415

I believe we should adapt default to make it work with 22.3 instead of pinning the version. I will have a look tomorrow.

If you think that's worth it...

@zakkak
Copy link
Collaborator

zakkak commented Sep 19, 2023

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 :)

@zakkak
Copy link
Collaborator

zakkak commented Sep 20, 2023

@roberttoyonaga now that #577 is merged could you please change the build type in the mandrel.yml workflow to mandrel-source-nolocalmvn and keep the @default pinning?

You can do so by adding the following line below with: in each job:

     build-type: "mandrel-source-nolocalmvn"

@zakkak zakkak merged commit 08cc6a0 into graalvm:mandrel/22.3 Sep 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

affects/22.3 backport OCA Verified All contributors have signed the Oracle Contributor Agreement.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants