search

Karm / mandrel-integration-tests

Integration tests for GraalVM and its Mandrel distribution. Runs Quarkus, Helidon and Micronaut applications and small targeted reproducers. The focus is solely on native-image utility and compilation of Java applications into native executables.
Apache License 2.0
5 stars 3 forks source link

JFR tests: Use current Mandrel version infra #118

Closed Karm closed 1 year ago

Karm commented 1 year ago

Reshuffled JFR smoke test template in preparation for more JFR tests. Moved compatibility matrix in test workflow.

jerboaa commented 1 year ago

It looks good to me. Have you tested this with a recent 22.3-dev build?

jerboaa commented 1 year ago

Related #107

Karm commented 1 year ago

It looks good to me. Have you tested this with a recent 22.3-dev build?

Yes and it works.

Karm commented 1 year ago

-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:

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

roberttoyonaga commented 1 year ago

-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?

Karm commented 1 year ago

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
Karm commented 1 year ago

Likely a GH actions glitch? Re-run went fine...

Karm commented 1 year ago

@roberttoyonaga, Thank you for the analysis. I adjusted the test suite accordingly.