Enable the use of JFR at native-image build time

[zakkak]

Feature request

Enable the use of Java Flight Recorder (JFR) to profile the native image driver itself, i.e. by passing -J-XX:StartFlightRecording to native-image.

Is your feature request related to a problem? Please describe.

Being able to profile and better understand what's happening during native-image generation is a key prerequisite in optimizing it.

Describe the solution you'd like.

We should be able to pass -J-XX:StartFlightRecording to native-image and enable profiling of the native image driver on the host VM, this however should not impact the code being compiled to native image.

Ideally passing -J-XX:StartFlightRecording to native-image should also be compatible with -H:+AllowVMInspection.

Describe who do you think will benefit the most.
GraalVM contributors.

Additional context.

The issues observed that far are:

1. Passing -J-XX:StartFlightRecording alters the behavior of the code being compiled by native-image, e.g. java.lang.Error.<init> is being compiled with embed JFR instrumentation calls while an instrumented java.lang.Error.<init> should only be used on the host JVM.
2. Passing -J-XX:StartFlightRecording results in various JFR-related classes being initialized and embed in the image heap. This not only results in larger image sizes but also breaks JFR support in the generated native image since various elements of JFR get preconfigured at build-time.

Express whether you'd like to help contributing this feature

Yes

[zakkak]

Trying on GraalVM built from e00d063 the following:

native-image -J-XX:StartFlightRecording=dumponexit=true,filename=demorecording.jfr --no-fallback -H:+ReportExceptionStackTraces HelloWorld

results in

Error: Unsupported features in 4 methods
Detailed message:
Error: com.oracle.graal.pointsto.constraints.UnresolvedElementException: Discovered unresolved method during parsing: jdk.jfr.internal.EventWriter.reset(). To diagnose the issue you can use the --allow-incomplete-classpath option. The missing method is then reported at run time when it is accessed the first time.
Trace: 
	at parsing jdk.jfr.internal.handlers.EventHandler1801_1638796418331-349261.write(Unknown Source)
Call path from entry point to jdk.jfr.events.ErrorThrownEvent.commit(): 
	at jdk.jfr.events.ErrorThrownEvent.commit(ErrorThrownEvent.java)
	at jdk.jfr.internal.instrument.ThrowableTracer.traceError(ThrowableTracer.java:44)
	at java.lang.Error.<init>(Error.java:71)
	at com.oracle.svm.jni.JNIJavaCallWrappers.jniInvoke_VA_LIST_Nonvirtual_Error_constructor_93acf2a68a79cb51e50a1255267d79a6aa671969(generated:0)
...

[zakkak]

This is being worked on by @christianwimmer in #4125

[christianwimmer]

#4125 is merged. At least for my purposes this is good enough. I still want to explicitly state the current restrictions here too:

• Turning flight recorder on for the image builder automatically also add flight recorder support in the generated image. This can disturb the measurement a bit, since more code gets included in the image
• A few more classes are initialized at image build time, because some parts of the flight recorder are Java code and therefore run at image build time when profiling the image generator. This can make some image builds fail, when these classes are explicitly required to be initialized at run time by the application. If you see any real-world problems because of that, please open an issue for me and I can see if we can refine the initialization strategy.
• Since flight recorder is not supported on Windows at run time, it is also not supported at image build time to profile the image generator.