Skip to content
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

Add Java Flight Recorder support #1154

Merged
merged 8 commits into from
Sep 4, 2024
Merged

Add Java Flight Recorder support #1154

merged 8 commits into from
Sep 4, 2024

Conversation

DanielThomas
Copy link
Member

This adds Java Flight Recorder support using JFR Event Streaming to begin adding measures that are not available via other means. For starters this includes per-process CPU load, Virtual Threads and ZGC.

Event Streaming was added in JDK 14, so I've anchored this to the nearest LTS using a Multi-Release jar so the classes are only visible on supported releases.

I need to dig deeper, but at a glance all of the current registerStandardMXBeans and GcLogger measures could be handled by JFR events instead. Unless there are any concerns, I'll follow this up with replacements for all of these standard measures with an jfr prefix so we can confirm parity with the jvm metrics in the real world.

@brharrington brharrington added this to the 1.7.20 milestone Aug 29, 2024
@brharrington
Copy link
Contributor

I'll follow this up with replacements for all of these standard measures with an jfr prefix so we can confirm parity with the jvm metrics in the real world.

That is fine for testing, but we do not want users to have to deal with this. They shouldn't need to care how we get the data and I don't want to create a separate copy that could start getting some use and require migration efforts.

@DanielThomas
Copy link
Member Author

I'll follow this up with replacements for all of these standard measures with an jfr prefix so we can confirm parity with the jvm metrics in the real world.

That is fine for testing, but we do not want users to have to deal with this. They shouldn't need to care how we get the data and I don't want to create a separate copy that could start getting some use and require migration efforts.

Oh yeah, totally the intention that's temporary and then rename them to jvm.* to replace the JMX metrics, so we can switch to just registering JFR on JDK 17 and later (i.e Spring Boot 3+).

@DanielThomas
Copy link
Member Author

In fact, looks like getting parity with GcLogger is tricky with JFR, because the events we'd need are only in G1, so I'll leave that alone. I have added parity with Jmx.registerStandardMXBeans so those measures can be avoided if JavaFlightRecorder.isSupported.

@brharrington
Copy link
Contributor

In fact, looks like getting parity with GcLogger is tricky with JFR, because the events we'd need are only in G1, so I'll leave that alone

Interesting, do you know if that is something that the JDK team is looking at? What are the specific gaps? I think jdk.GarbageCollection would cover the main pause times. Concurrent phase time and before and after memory pool sizes is a bit less clear from my quick skimming.

Copy link
Contributor

@brharrington brharrington left a comment

Choose a reason for hiding this comment

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

Since Jmx.registerStandardMXBeans is the main entry point used by various integrations, I think we can have it choose JFR internally when available. This would allow it to automatically transition without having to update all of different uses. Might need to have some flag to force the old behavior for testing, I'll think about that.

The GcLogger is a bit trickier, but since that isn't in scope for now can worry about that later.

@DanielThomas
Copy link
Member Author

DanielThomas commented Sep 3, 2024

In fact, looks like getting parity with GcLogger is tricky with JFR, because the events we'd need are only in G1, so I'll leave that alone

Interesting, do you know if that is something that the JDK team is looking at? What are the specific gaps? I think jdk.GarbageCollection would cover the main pause times. Concurrent phase time and before and after memory pool sizes is a bit less clear from my quick skimming.

I'll put a ticket in my backlog to follow up with them on lack of support for these events in the other collectors. (Edit: JVM-335)

@DanielThomas DanielThomas force-pushed the dannyt/jfr branch 3 times, most recently from 8b0774b to 6f70c0a Compare September 3, 2024 02:39
DanielThomas and others added 3 commits September 4, 2024 00:50
make indentation consistent
Hold reference to thread count gauges
@brharrington brharrington merged commit bcdd2e5 into main Sep 4, 2024
1 check passed
@brharrington brharrington deleted the dannyt/jfr branch September 4, 2024 02:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants