Closed Karm closed 1 year ago
It looks good to me. Have you tested this with a recent 22.3-dev build?
Related #107
It looks good to me. Have you tested this with a recent 22.3-dev build?
Yes and it works.
Hello @jerboaa, @roberttoyonaga,
I just wanted to remove -XX:+FlightRecorder
from the test suite, thinking it's not needed as per JDK-8225312. I ended up removing it only for JDK 17 HotSpot mode, because:
-XX:+FlightRecorder
...O.K. Yet perhaps unnecessarily inconsistent with JVM then?org.opentest4j.AssertionFailedError: Application JFR_SMOKE_BUILDER_IMAGE in mode jvm_jfr
took 8337 ms to finish, which is over 6924 ms threshold by 20%. ==> expected: <true> but was: <false>
Question: What am I misunderstanding about JDK-8225312? The way I read it, the option didn't do anything for thread buffer for JDK 11 as it was already too new...?
Thanks for hints
-XX:+FlightRecorder
Hello @jerboaa, @roberttoyonaga, I just wanted to remove
-XX:+FlightRecorder
from the test suite, thinking it's not needed as per JDK-8225312. I ended up removing it only for JDK 17 HotSpot mode, because:
- native image runtime needs it, i.e. it requires
-XX:+FlightRecorder
...O.K. Yet perhaps unnecessarily inconsistent with JVM then?- JDK 11 works without it, but the performance of the example app test drops dramatically (yes, ran it several times):
org.opentest4j.AssertionFailedError: Application JFR_SMOKE_BUILDER_IMAGE in mode jvm_jfr took 8337 ms to finish, which is over 6924 ms threshold by 20%. ==> expected: <true> but was: <false>
Question: What am I misunderstanding about JDK-8225312? The way I read it, the option didn't do anything for thread buffer for JDK 11 as it was already too new...?
Thanks for hints
It seems like in JDK11, hotspot still checks whether the FlightRecorderFlag was specified and does additional work at start up. . See the check here: https://github.com/openjdk/jdk11/blob/master/src/hotspot/share/jfr/recorder/jfrRecorder.cpp#L59
Which causes _enabled
to be set to true
here:
https://github.com/openjdk/jdk11/blob/master/src/hotspot/share/jfr/recorder/jfrRecorder.cpp#L79
Which results in this extra work at start up:
https://github.com/openjdk/jdk11/blob/master/src/hotspot/share/jfr/recorder/jfrRecorder.cpp#L223
That conditional extra work is not present in jdk17 it seems: https://github.com/openjdk/jdk17/blob/master/src/hotspot/share/jfr/recorder/jfrRecorder.cpp#L222
Maybe doing this extra step at startup somehow saves time?
Hmm, seemingly unrelated failure when testing builder image and encoding for Quarkus app, the warning does not show locally for me:
[INFO] --- quarkus-maven-plugin:2.13.0.Final:build (default) @ quarkus-spoklik-encoding ---
[INFO] [io.quarkus.deployment.pkg.steps.JarResultBuildStep] Building native image source jar: /home/runner/work/mandrel-integration-tests/mandrel-integration-tests/ts/builder-image-apps/quarkus-spöklik-encoding/target/quarkus-spoklik-encoding-1.0.0-SNAPSHOT-native-image-source-jar/quarkus-spoklik-encoding-1.0.0-SNAPSHOT-runner.jar
[INFO] [io.quarkus.deployment.pkg.steps.NativeImageBuildStep] Building native image from /home/runner/work/mandrel-integration-tests/mandrel-integration-tests/ts/builder-image-apps/quarkus-spöklik-encoding/target/quarkus-spoklik-encoding-1.0.0-SNAPSHOT-native-image-source-jar/quarkus-spoklik-encoding-1.0.0-SNAPSHOT-runner.jar
[INFO] [io.quarkus.deployment.pkg.steps.NativeImageBuildContainerRunner] Using docker to run the native image builder
Exception in thread "Process stdout" java.lang.RuntimeException: Error reading stream.
at io.quarkus.deployment.OutputFilter.lambda$apply$0(OutputFilter.java:23)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.io.IOException: Stream closed
at java.base/java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:176)
at java.base/java.io.BufferedInputStream.read(BufferedInputStream.java:342)
at java.base/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
at java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
at java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
at java.base/java.io.InputStreamReader.read(InputStreamReader.java:181)
at java.base/java.io.BufferedReader.fill(BufferedReader.java:161)
at java.base/java.io.BufferedReader.readLine(BufferedReader.java:326)
at java.base/java.io.BufferedReader.readLine(BufferedReader.java:392)
at io.quarkus.deployment.OutputFilter.lambda$apply$0(OutputFilter.java:19)
... 1 more
[INFO] [io.quarkus.deployment.pkg.steps.NativeImageBuildContainerRunner] Checking image status quay.io/quarkus/ubi-quarkus-mandrel:22.2-java11
Likely a GH actions glitch? Re-run went fine...
@roberttoyonaga, Thank you for the analysis. I adjusted the test suite accordingly.
Reshuffled JFR smoke test template in preparation for more JFR tests. Moved compatibility matrix in test workflow.