Git Product home page Git Product logo

Comments (7)

fniephaus avatar fniephaus commented on June 9, 2024

the fallback still seems to run without the parameter because I get an exception for faulty class versions

What do you mean by fallback? Does Native Image generate a fallback image for your application? What error do you get when you build with --no-fallback?

from graal.

pjonsson avatar pjonsson commented on June 9, 2024

the fallback still seems to run without the parameter because I get an exception for faulty class versions

What do you mean by fallback? Does Native Image generate a fallback image for your application? What error do you get when you build with --no-fallback?

Building with fallback = false in build.gradle gives a few pages of errors about initializing various parts of slf4j, output pasted below.

Even if that worked, I would still end up in SymbolLookup.libraryLookup().find() in the end, and that isn't supported by native-image as far as I know.

Error: Unsupported features in 2 methods
Detailed message:
Error: An object of type 'org.slf4j.helpers.NOP_FallbackServiceProvider' 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.slf4j.helpers.NOP_FallbackServiceProvider' are persisted in the image heap, add 

    '--initialize-at-build-time=org.slf4j.helpers.NOP_FallbackServiceProvider'

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.slf4j.helpers.NOP_FallbackServiceProvider' 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.slf4j.helpers.NOP_FallbackServiceProvider'

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 enabling '--strict-image-heap', 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.slf4j.helpers.NOP_FallbackServiceProvider' 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.
Please address this problem to be prepared for future releases of GraalVM.

The following detailed trace displays from which field in the code the object was reached.
Trace: Object was reached by
  trying to constant fold static field org.slf4j.LoggerFactory.NOP_FALLBACK_SERVICE_PROVIDER
    at org.slf4j.LoggerFactory.getProvider(LoggerFactory.java:498)
  parsing method org.slf4j.LoggerFactory.getProvider(LoggerFactory.java:486) reachable via the parsing context
    at static root method.(Unknown Source)

Error: An object of type 'org.slf4j.helpers.SubstituteServiceProvider' 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.slf4j.helpers.SubstituteServiceProvider' are persisted in the image heap, add 

    '--initialize-at-build-time=org.slf4j.helpers.SubstituteServiceProvider'

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.slf4j.helpers.SubstituteServiceProvider' 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.
                       4.4s (17.2% of total time) in 109 GCs | 
Peak RSS: 4.48GB | CPU load: 11.47
2) If these objects should not be stored in the image heap, you can use 

    '--trace-object-instantiation=org.slf4j.helpers.SubstituteServiceProvider'
========================================================================================================================

Finished generating 'cooja' in 24.8s.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 enabling '--strict-image-heap', 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.slf4j.helpers.SubstituteServiceProvider' 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.
Please address this problem to be prepared for future releases of GraalVM.

The following detailed trace displays from which field in the code the object was reached.
Trace: Object was reached by
  trying to constant fold static field org.slf4j.LoggerFactory.SUBST_PROVIDER
    at org.slf4j.LoggerFactory.getProvider(LoggerFactory.java:504)
  parsing method org.slf4j.LoggerFactory.getProvider(LoggerFactory.java:486) reachable via the parsing context
    at static root method.(Unknown Source)



> Task :nativeCompile FAILED

from graal.

pjonsson avatar pjonsson commented on June 9, 2024

@fniephaus Sorry, I might have misinterpreted your comment, are you saying --enable-preview is not supported when a fallback image is built?

from graal.

fniephaus avatar fniephaus commented on June 9, 2024

Building with fallback = false in build.gradle gives a few pages of errors about initializing various parts of slf4j, output pasted below.

Ok, so this means that your app cannot be turned into a native image. Instead, a fallback image is created, which is essentially a thin launcher that runs your app on HotSpot. I'm not sure this is what you want?

Sorry, I might have misinterpreted your comment, are you saying --enable-preview is not supported when a fallback image is built?

When --enable-preview is passed into a build, preview features should be available, even in the fallback image (as you said). So this could be a bug in the generation of fallback images.

Even if that worked, I would still end up in SymbolLookup.libraryLookup().find() in the end, and that isn't supported by native-image as far as I know.

According to this, I think you are right.

from graal.

pjonsson avatar pjonsson commented on June 9, 2024

Ok, so this means that your app cannot be turned into a native image. Instead, a fallback image is created, which is essentially a thin launcher that runs your app on HotSpot. I'm not sure this is what you want?

My (unfounded) impression was that native-image would make a binary that had as much as possible as machine code, and then insert code to switch to executing on the JVM for some suitably selected part of the program. I realize the hand waving aspect of the terms "as much as possible" and "suitably selected".

So you are right, a fallback image is not really what I want, and I wasn't expecting the "suitably selected" part of the program to be 100%. But being able to run ./gradlew nativeRun would make it possible to merge various bits and pieces (build support, etc) to main, which would make it easier for others to contribute, so having this issue solved would improve the situation.

Our build.gradle is fairly standard as far as I know, so my guess is that others who use preview (and incubator?) features could also be affected by this issue.

from graal.

fniephaus avatar fniephaus commented on June 9, 2024

My (unfounded) impression was that native-image would make a binary that had as much as possible as machine code, and then insert code to switch to executing on the JVM for some suitably selected part of the program. I realize the hand waving aspect of the terms "as much as possible" and "suitably selected".

We are working on some ideas that might allow to do this in the future, but currently, a fallback image simply calls out to HotSpot. Here's the relevant code in case you are interested:

* This class is used to generate fallback images in case we are unable to build standalone images.
*
* A fallback image is a trivial standalone image that delegates execution of the application that
* should originally be built to calling the Java executable with the original image classpath and
* mainClass. System-properties specified during the original image-build get passed to the Java
* executable that the FallbackExecutor uses to run the application.
*
* Control gets transferred to the Java executable by using {code}ProcessProperties.exec(){code}.
* This ensures that the fallback image behaves as if the original application was started as
* regular Java application.

Our build.gradle is fairly standard as far as I know, so my guess is that others who use preview (and incubator?) features could also be affected by this issue.

Sure, that can very well be the case. We are still working on the Foreign Function & Memory API for Native Image.

from graal.

fniephaus avatar fniephaus commented on June 9, 2024

FYI, we just added #8113 for the FFM API in Native Image to the roadmap (in case you'd like to stay updated).

from graal.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.