Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for a smoke test specifying its required version of Java #218

Closed
wilkinsona opened this issue Apr 25, 2024 · 6 comments
Closed
Assignees

Comments

@wilkinsona
Copy link
Member

data:data-jdbc-h2-kotlin:nativeTest requires Java 22. We should allow a smoke test to indicate that it requires a particular version of Java and then honour this requirement in the generated workflows.

@wilkinsona wilkinsona self-assigned this Apr 25, 2024
@wilkinsona
Copy link
Member Author

Gradle itself does not yet support running on Java 22 so we'll have to use toolchains for this. Unfortunately, toolchains support with GraalVM is also somewhat limited:

Again, be aware that the toolchain detection cannot distinguish between GraalVM JDKs and standard JDKs without Native Image support: if you have both installed on the machine, Gradle may randomly pick one or the other.

This will work fine on CI where we can have GraalVM installed and nothing else. It will, however, make it difficult to reliably run the smoke tests locally.

There's a reasonable amount of work required here and the benefit isn't quite as much as I'd hoped it would be if we need to target Java 22. I'm wondering if we should just remove the unit test parts of data:data-jdbc-h2-kotlin until we can run Gradle itself on Java 22.

WDYT, @sdeleuze?

wilkinsona added a commit that referenced this issue Apr 25, 2024
The current format makes things like gh-218 quite difficult. By
reworking the format it will be easier to extend the configuration
options in the future.
@sdeleuze
Copy link
Collaborator

Toolchain support with native is indeed not something I would recommend to use with native, but a possible alternative is keep our existing JDK to run Gradle and set a GRAALVM_HOME environnement variable to the Java 22 distribution of GraalVM to use to compile to native (this is what I used locally).

If this is too much work or not ideal, we can indeed remove that unit test or configure the following if this is supported:


aotSmokeTest {
    nativeTest {
           expectedToFail {
              becauseOf "Require GraalVM for Java 22 to fix the build time initialization issue in tests"
           }
        }
}

What solution do you prefer @wilkinsona?

@wilkinsona
Copy link
Member Author

I tried using Liberica-NIK-24.0.1-1 but it failed:

GRAALVM_HOME=/Users/awilkinson/.sdkman/candidates/java/24.0.1.r22-nik ./gradlew :data:data-jdbc-h2-kotlin:nativeTestCompile --no-scan

> Task :data:data-jdbc-h2-kotlin:nativeTestCompile
[native-image-plugin] GraalVM Toolchain detection is disabled
[native-image-plugin] GraalVM location read from environment variable: GRAALVM_HOME
[native-image-plugin] Native Image executable path: /Users/awilkinson/.sdkman/candidates/java/24.0.1.r22-nik/lib/svm/bin/native-image
Warning: The option '-H:Path=/Users/awilkinson/dev/spring-projects/spring-aot-smoke-tests/3.2.x/data/data-jdbc-h2-kotlin/build/native/nativeTestCompile' is experimental and must be enabled via '-H:+UnlockExperimentalVMOptions' in the future.
Warning: The option '-H:Name=data-jdbc-h2-kotlin-tests' is experimental and must be enabled via '-H:+UnlockExperimentalVMOptions' in the future.
Warning: The option '-H:+BuildOutputColorful' is experimental and must be enabled via '-H:+UnlockExperimentalVMOptions' in the future.
Warning: Please re-evaluate whether any experimental option is required, and either remove or unlock it. The build output lists all active experimental options, including where they come from and possible alternatives. If you think an experimental option should be considered as stable, please file an issue.
Warning: Option 'BuildOutputColorful' is deprecated and might be removed in a future release: Please use '--color' instead.. Please refer to the GraalVM release notes.
========================================================================================================================
GraalVM Native Image: Generating 'data-jdbc-h2-kotlin-tests' (executable)...
========================================================================================================================
[1/8] Initializing...                                                                                    (8.8s @ 0.22GB)
 Java version: 22.0.1+10, vendor version: Liberica-NIK-24.0.1-1
 Graal compiler: optimization level: 2, target machine: x86-64-v3
 C compiler: cc (apple, x86_64, 15.0.0)
 Garbage collector: Serial GC (max heap size: 80% of RAM)
 3 user-specific feature(s):
 - com.oracle.svm.thirdparty.gson.GsonFeature
 - org.graalvm.junit.platform.JUnitPlatformFeature
 - org.springframework.aot.nativex.feature.PreComputeFieldFeature
------------------------------------------------------------------------------------------------------------------------
 3 experimental option(s) unlocked:
 - '-H:Name' (alternative API option(s): -o data-jdbc-h2-kotlin-tests; origin(s): command line)
 - '-H:Path': Use the '-o' option instead. (origin(s): command line)
 - '-H:+BuildOutputColorful' (origin(s): command line)
------------------------------------------------------------------------------------------------------------------------
Build resources:
 - 24.18GB of memory (75.6% of 32.00GB system memory, determined at start)
 - 16 thread(s) (100.0% of 16 available processor(s), determined at start)
[junit-platform-native] Running in 'test listener' mode using files matching pattern [junit-platform-unique-ids*] found in folder [/Users/awilkinson/dev/spring-projects/spring-aot-smoke-tests/3.2.x/data/data-jdbc-h2-kotlin/build/test-results/test/testlist] and its subfolders.
SLF4J(W): No SLF4J providers were found.
SLF4J(W): Defaulting to no-operation (NOP) logger implementation
SLF4J(W): See https://www.slf4j.org/codes.html#noProviders for further details.
[2/8] Performing analysis...  [******]                                                                  (35.8s @ 2.96GB)
   21,649 reachable types   (88.6% of   24,445 total)
   37,112 reachable fields  (61.5% of   60,345 total)
  111,259 reachable methods (63.3% of  175,741 total)
    7,571 types,   651 fields, and 5,575 methods registered for reflection
      185 types,   266 fields, and   200 methods registered for JNI access
       16 native libraries: -framework Accelerate, -framework Carbon, -framework Cocoa, -framework CoreServices, -framework Foundation, -framework JavaRuntimeSupport, -framework Metal, -framework OpenGL, -framework QuartzCore, -framework Security, dl, m, pthread, stdc++, z

Error: An object of type 'org.junit.platform.launcher.core.SessionPerRequestLauncher' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.
------------------------------------------------------------------------------------------------------------------------

You now have two options to resolve this:

1) If it is intended that objects of type 'org.junit.platform.launcher.core.SessionPerRequestLauncher' are persisted in the image heap, add 

    '--initialize-at-build-time=org.junit.platform.launcher.core.SessionPerRequestLauncher'

to the native-image arguments. Note that initializing new types can store additional objects to the heap. It is advised to check the static fields of 'org.junit.platform.launcher.core.SessionPerRequestLauncher' to see if they are safe for build-time initialization,  and that they do not contain any sensitive data that should not become part of the image.

2) If these objects should not be stored in the image heap, you can use 

    '--trace-object-instantiation=org.junit.platform.launcher.core.SessionPerRequestLauncher'

to find classes that instantiate these objects. Once you found such a class, you can mark it explicitly for run time initialization with 

    '--initialize-at-run-time=<culprit>'

to prevent the instantiation of the object.

If you are seeing this message after upgrading to a new GraalVM release, this means that some objects ended up in the image heap without their type being marked with --initialize-at-build-time.
To fix this, include '--initialize-at-build-time=org.junit.platform.launcher.core.SessionPerRequestLauncher' in your configuration. If the classes do not originate from your code, it is advised to update all library or framework dependencies to the latest version before addressing this error.

The following detailed trace displays from which field in the code the object was reached.
Detailed message:
Trace: Object was reached by
  reading field org.graalvm.junit.platform.NativeImageJUnitLauncher.launcher of constant 
    org.graalvm.junit.platform.NativeImageJUnitLauncher@dee505f: org.graalvm.junit.platform.NativeImageJUnitLauncher@dee505f
  manually created constant

                       7.0s (14.9% of total time) in 144 GCs | Peak RSS: 4.10GB | CPU load: 10.64
========================================================================================================================
Failed generating 'data-jdbc-h2-kotlin-tests' after 45.3s.

> Task :data:data-jdbc-h2-kotlin:nativeTestCompile FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':data:data-jdbc-h2-kotlin:nativeTestCompile'.
> Process 'command '/Users/awilkinson/.sdkman/candidates/java/24.0.1.r22-nik/bin/native-image'' finished with non-zero exit value 1

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.

* Get more help at https://help.gradle.org

BUILD FAILED in 1m
14 actionable tasks: 1 executed, 13 up-to-date

This is a different and earlier failure than we are seeing with 22.3.5.

@sdeleuze
Copy link
Collaborator

I can reproduce, I have created graalvm/native-build-tools#598 related issue.

@sdeleuze
Copy link
Collaborator

Based on my discussion with the GraalVM team and my latest tests, we need to use both NBT 0.10.1+ and GraalVM 22+ to make this test working, so I suspect it was tested with an older version of NBT (we are using NBT 0.9.25 in the 3.2.x branch for example). So maybe we can uncomment the expected failure configuration just in main (that is already using NBT 0.10.1) and customize the GraalVM version to 22?

@wilkinsona
Copy link
Member Author

Confirmed. Thanks, @sdeleuze. It works fine on main so I'll update the failure expectations accordingly. With that, I think we're done here as we have the necessary support for configuring the version of Graal/Java that's used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants