Skip to content

8286707: JFR: Don't commit JFR internal jdk.JavaMonitorWait events #8883

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 7 commits into from
Closed

8286707: JFR: Don't commit JFR internal jdk.JavaMonitorWait events #8883

wants to merge 7 commits into from

Conversation

@jaokim
Copy link
Contributor

@jaokim jaokim commented May 25, 2022 •
edited by openjdk bot
Loading

Changed the JFR chunk rotation lock object to specific internal class. This allows that specific Object.wait() event to be skipped, thus not adding JFR internal noise to recordings.

Testing

  • jdk_jfr

Progress

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue

Issue

  • JDK-8286707: JFR: Don't commit JFR internal jdk.JavaMonitorWait events

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/8883/head:pull/8883
$ git checkout pull/8883

Update a local copy of the PR:
$ git checkout pull/8883
$ git pull https://git.openjdk.org/jdk pull/8883/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 8883

View PR using the GUI difftool:
$ git pr show -t 8883

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/8883.diff

@bridgekeeper
Copy link

bridgekeeper bot commented May 25, 2022

👋 Welcome back jnordstrom! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk openjdk bot added the rfr Pull request is ready for review label May 25, 2022
@openjdk
Copy link

openjdk bot commented May 25, 2022

@jaokim The following label will be automatically applied to this pull request:

  • hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

@mlbridge
Copy link

mlbridge bot commented May 25, 2022 •
edited
Loading

Webrevs

@openjdk
Copy link

openjdk bot commented May 26, 2022

@dholmes-ora
The label hotsppot-jfr is not a valid label.
These labels are valid:

  • serviceability
  • hotspot
  • hotspot-compiler
  • ide-support
  • kulla
  • i18n
  • shenandoah
  • jdk
  • javadoc
  • security
  • hotspot-runtime
  • jmx
  • build
  • nio
  • client
  • core-libs
  • compiler
  • net
  • hotspot-gc
  • hotspot-jfr

@dholmes-ora
Copy link
Member

dholmes-ora commented May 26, 2022

/label add hotspot-jfr

@openjdk
Copy link

openjdk bot commented May 26, 2022

@dholmes-ora
The hotspot-jfr label was successfully added.

dholmes-ora
dholmes-ora suggested changes May 26, 2022
View reviewed changes
Copy link
Member

@dholmes-ora dholmes-ora left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think any filtering should be handled internally to JFR not in the ObjectMonitor code.

@openjdk
Copy link

openjdk bot commented May 26, 2022

@dholmes-ora The hotspot-jfr label was already applied.

@bridgekeeper
Copy link

bridgekeeper bot commented Jun 23, 2022

@jaokim This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

@bridgekeeper
Copy link

bridgekeeper bot commented Jul 21, 2022

@jaokim This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.

@bridgekeeper bridgekeeper bot closed this Jul 21, 2022
@jaokim
Copy link
Contributor Author

jaokim commented Oct 14, 2022

/open

@openjdk openjdk bot reopened this Oct 14, 2022
@openjdk
Copy link

openjdk bot commented Oct 14, 2022

@jaokim This pull request is now open

@jaokim jaokim marked this pull request as draft October 14, 2022 08:51
@openjdk openjdk bot removed the rfr Pull request is ready for review label Oct 14, 2022
@jaokim jaokim marked this pull request as ready for review October 14, 2022 12:00
@openjdk openjdk bot added the rfr Pull request is ready for review label Oct 14, 2022
@jaokim
Copy link
Contributor Author

jaokim commented Oct 14, 2022

I've re-opened this, and made slight alterations after suggestions from @mgronlun

@openjdk
Copy link

openjdk bot commented Oct 14, 2022 •
edited
Loading

@jaokim 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:

8286707: JFR: Don't commit JFR internal jdk.JavaMonitorWait events

Reviewed-by: dholmes, egahlin

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 76 new commits pushed to the master branch:

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.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@dholmes-ora, @egahlin) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

@openjdk openjdk bot added the ready Pull request is ready to be integrated label Oct 14, 2022
dholmes-ora
dholmes-ora reviewed Oct 17, 2022
View reviewed changes
Copy link
Member

@dholmes-ora dholmes-ora left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am still not happy about this approach. JFR is written in Java and so triggers numerous events that are defined for Java code - that is a simple consequence of implementing it in Java. If there is to be filtering of events that originate from JFR Java code then there should be a general purpose filtering mechanism available to say "exclude JFR code" or "include JFR code" as desired. And to me the filtering mechanism should reside in the event commit code inside the JFR code not in the event-posting code in the shared components of the VM.

@mgronlun
Copy link

mgronlun commented Oct 17, 2022

There exist a general exclusion/inclusion mechanism already. But it is an all-or-nothing proposition. This particular case is a thread that we can't exclude because it runs the periodic events, upon being notified. It is the notification mechanism to run the periodic events that trigger this large amount of unnecessary MonitorWait events. Even should we change it to some util.concurrent construct, we are only pushing the problem, because we might be instrumenting them later too. To work with the existing exclusion mechanism, the system would have to introduce an additional thread, which will be excluded, which only handles the notification, and then by some other means triggers another periodic thread (included) to run the periodic events.

@dholmes-ora
Copy link
Member

dholmes-ora commented Oct 18, 2022

@mgronlun my request is that this filtering be done inside the commit logic by the JFR code, not at the site where the event is generated - ie this internal-jfr-event filtering is internalized into the JFR code.

@mgronlun
Copy link

mgronlun commented Oct 18, 2022

@dholmes-ora I agree that would be preferable indeed. Unfortunately, it cannot be done without introducing overhead to all event types and all event commit sites.

@jaokim
Copy link
Contributor Author

jaokim commented Oct 18, 2022

Would it be possible to add this filtering as part of the throttling mechanism? I guess it would push the meaning of throttling, and might be overkill for this specific use-case, but perhaps some new internal throttle-like approach could be implemented?
I'll do some experimentation and see what I might come up with.

@jaokim
Copy link
Contributor Author

jaokim commented Oct 19, 2022

I'm realizing that the monitor class isn't available elsewhere; it is in objectMonitor.cpp, and passed to private members in the JavaObjectMonitorEvent, which in turn is generated. The only possibility I see to moving the logic away from objectMonitor.cpp is to change how the event's classes are generated. Either by adding getter to certain members (in this case something like get_monitorClass to JavaObjectMonitorEvent), or trying to shoehorn the is_excluded method into the generated JavaObjectMonitorEvent. Neither of these approaches would I say are even worth considering, and they'd also still introduce overhead.

dholmes-ora
dholmes-ora approved these changes Oct 19, 2022
View reviewed changes
Copy link
Member

@dholmes-ora dholmes-ora left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for making the effort to investigate alternatives, it is appreciated.

@jaokim
Copy link
Contributor Author

jaokim commented Oct 19, 2022

Thank you for reviewing and comments, @dholmes-ora, @egahlin and @mgronlun!

Would anyone of you sponsor this as well? Thanks!

@jaokim
Copy link
Contributor Author

jaokim commented Oct 19, 2022

/integrate

@openjdk openjdk bot added the sponsor Pull request is ready to be sponsored label Oct 19, 2022
@openjdk
Copy link

openjdk bot commented Oct 19, 2022

@jaokim
Your change (at version a1a95ed) is now ready to be sponsored by a Committer.

@mgronlun
Copy link

mgronlun commented Oct 19, 2022

/sponsor

@openjdk
Copy link

openjdk bot commented Oct 19, 2022

Going to push as commit fc88957.
Since your change was applied there have been 76 commits pushed to the master branch:

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Oct 19, 2022
@openjdk openjdk bot closed this Oct 19, 2022
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review sponsor Pull request is ready to be sponsored labels Oct 19, 2022
@openjdk
Copy link

openjdk bot commented Oct 19, 2022

@mgronlun @jaokim Pushed as commit fc88957.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@roberttoyonaga roberttoyonaga mentioned this pull request Sep 29, 2023
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

2 more reviewers

@egahlin egahlin egahlin approved these changes

@dholmes-ora dholmes-ora dholmes-ora approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

hotspot [email protected] hotspot-jfr [email protected] integrated Pull request has been integrated

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@jaokim @dholmes-ora @mgronlun @egahlin