Comments (7)
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.
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.
@fniephaus Sorry, I might have misinterpreted your comment, are you saying --enable-preview
is not supported when a fallback image is built?
from graal.
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.
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.
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:
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.
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)
- [GR-51641] Compilation execution fails at the last step, Error: Id: Undefined symbols, _Java_java_lang_VirtualThread_notifyJvmtiEnd HOT 17
- cannot install scipy with graalpy-23.1.2-macos-aarch64.tar.gz HOT 6
- InternalResourceCache is hard-coded to 'user.home'. Overriding the path fails in tests. HOT 7
- Error reading tcl file - Cannot read resource "/tcl/lang/library/init.tcl" HOT 1
- Make graalnodejs-community available in `nvm-sh/nvm` and `coreybutler/nvm-windows`
- [GR-51307] Unable to collect GC data with NotificationEmitter in native build HOT 10
- orai18n dependency causes native application startup failure - Missing character set id 560 HOT 11
- UnsatisfiedLinkError: No awt in java.library.path HOT 6
- Determine the locale of Native Image executables at run-time
- [GR-51862] Native image build fails when using quarkus and protobuf HOT 5
- Native image service unable to compress image HOT 1
- Warning caused by Truffle and Polyglot HOT 4
- GraalVM native with kotlin issue HOT 3
- A way to limit instructions per execution (mainly for wasm) HOT 3
- [GR-51934] MacOS UnsatisfiedLinkError: sun.security.krb5.SCDynamicStoreConfig.getKerberosConfig HOT 1
- [GR-52221] Allow native-image-plugin to use a docker image as executable HOT 2
- maven java app fail with 'Error: No main manifest attribute' HOT 2
- [GR-52220] Support for Cosmopolitan Libc HOT 4
- [GR-52023] Re-evaluate LibC.abort implementation HOT 2
- [GR-52021] Getting NullPointerException instead of something that tells me what is wrong HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from graal.