have jfr on windows be a noop until full jfr available

[maxandersen]

Feature request

Please include the following information:

Is your feature request related to a problem? Please describe.
if you use jfr in your java code it builds on linux/osx when jfr is enabled but on windows it will always fail with a runtime error.

This means I can't easily add JFR to my java code without burdensome limits.

Describe the solution you'd like.
That JFR on windows does not fail and simply becomes a noop in windows native image.

Describe who do you think will benefit the most.
graalvm users and framework devs can use JFR without fearing it will break on windows.

Describe alternatives you've considered.
guard all creation of jfrevent base classes with if(FlightRecorder.isAvailable()) but that is lots of noise.

Additional context.
tamboui/tamboui#284 where it was discovered native image on windows fails when creating jfr based classes so can't even call isEnabled().

see #5410

[oubidar-Abderrahim]

Thank you for sharing this, we'll take a look into it
cc @roberttoyonaga @fniephaus

[fniephaus]

So the easy workaround for this would be that we disable the JFR option automatically on Windows and print a warning? Similar to how we print a warning when the -g debugging option is used on macOS?

[roberttoyonaga]

So the easy workaround for this would be that we disable the JFR option automatically on Windows and print a warning?

This is actually essentially what we already do. On Windows, users are not allowed to use --enable-monitoring=jfr. They should get a build-time warning if they do (and the option is ignored). And if they use JFR at runtime (via -XX:StartFlightRecording) they will get a descriptive error and the VM will not start. If users start their app without -XX:StartFlightRecording the built-in JFR features gracefully noop on Windows.

The real problem is that if users want to use the JFR API in their application code, their app may fail on Windows. For example, if a user wants to use the JFR API new Recording() then they need to guard it with something like if (notWindows()) otherwise that JFR API will execute and the VM will fail with a descriptive error on Windows. This makes it hard to use the JFR API in a portable way in application-level code -- and may cause some users to avoid using JFR at all. This wouldn't be a problem if the JFR API surface was stubbed out to be noops on Windows.

I can think of 3 possible solutions:

1. Use substitutions to stub out the whole JFR API surface on windows to be noops. This will incur a maintenance burden and is brittle in my opinion. However, we already substitute a lot of JFR code, so there is a precedent for this.
2. Implement JFR on Windows. I talked briefly to @christianhaeubl about this too. Later this/next week I plan to spike how much effort this will be.
3. Encourage users to guard usages of the JFR API with jdk.jfr.FlightRecorder.isAvailable(). This will return false on Windows on NativeImage. This is the easiest option for us, but puts the burden on the users.

To complicate matters more, some parts of the JFR API are coincidentally already noops on Windows. For example, users can create and commit custom events without problems: MyEvent e = new MyEvent(); e.commit();. Only some parts of the JFR API cause the VM to exit early.

[thomaswue]

@roberttoyonaga I think adding basic JFR support on Windows seems a good option. I can start drafting a PR and then we can collaborate maybe on it.

[roberttoyonaga]

@roberttoyonaga I think adding basic JFR support on Windows seems a good option. I can start drafting a PR and then we can collaborate maybe on it.

Sure, that sounds good. I started working on this a little bit yesterday as well. I think the main thing that needs to be done is a Windows implementation of AbstractRawFileOperationSupport. Then, com.oracle.svm.core.windows.headers.FileAPI and com.oracle.svm.core.windows.headers.StringAPISet will need to be expanded a bit in order to support this.

The JFR emergency dumper and execution sampling (with SIGPROF) also rely on POSIX functionality. However, I think it is best to leave the Windows implementation of those features to a later date. We only need WindowsRawFileOperationSupport in order to get a minimal working JFR implementation on Windows.