Add Java Flight Recorder support

[DanielThomas]

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]

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]

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]

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]

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.

[brharrington]

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]

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)