[GR-60088] Add jdk.graal.nativeimage module. #10380
Conversation
oracle-contributor-agreement
bot
added
the
OCA Verified
graalvmbot
force-pushed
the
ds/GR-60088
branch
13 times, most recently
from
a229752 to
aeed0d5
Compare
graalvmbot
force-pushed
the
ds/GR-60088
branch
4 times, most recently
from
52e529a to
2f4508a
Compare
…vm.graal.hotspot.libgraal
graalvmbot
force-pushed
the
ds/GR-60088
branch
from
2f4508a to
584d4d0
Compare
graalvmbot
force-pushed
the
ds/GR-60088
branch
from
584d4d0 to
07a5f5d
Compare
graalvmbot
force-pushed
the
ds/GR-60088
branch
from
07a5f5d to
ffd8bc9
Compare
…tiveimage.jar and nativebridge.jar
…ed to FeatureComponent
…ed to FeatureComponent ++
graalvmbot
force-pushed
the
ds/GR-60088
branch
from
ffd8bc9 to
7542c2f
Compare
| @AutomaticallyRegisteredImageSingleton({VMRuntimeSupport.class, RuntimeSupport.class, LibGraalRuntimeSupport.class}) | ||
| public final class RuntimeSupport implements VMRuntimeSupport, LibGraalRuntimeSupport { | ||
|
|
||
| @Override |
There was a problem hiding this comment.
I think you should move all these new methods to a separate libgraal-specific image singleton that implements LibGraalRuntimeSupport (for a normal native image, it does not make sense to use any of these methods).
There was a problem hiding this comment.
Ok. Where would you suggest to put LibGraalRuntimeSupportImpl? In substratevm/src/com.oracle.svm.core/src/com/oracle/svm/core/libgraal/LibGraalRuntimeSupportImpl.java?
| * RuntimeSystemProperties.register(NATIVE_IMAGE_SETTING_KEY_PREFIX + "gc", "serial"); | ||
| * </pre> | ||
| */ | ||
| public static final String NATIVE_IMAGE_SETTING_KEY_PREFIX = "org.graalvm.nativeimage.setting."; |
There was a problem hiding this comment.
jdk.graal.compiler exports everything (*) to org.graalvm.nativeimage... which makes of course sense for hosted graal usage.
If I understand correctly, LibGraalFeature is guest graal only. I.e., org.graalvm.nativeimage... should not depend on it, or even have access to it, right? Otherwise, we might introduce dependencies from native image to a specific version of LibGraalFeature without noticing it.
Currently, we only access NATIVE_IMAGE_SETTING_KEY_PREFIX so not a problem. Still, would it make sense to separate it out LibGraalFeature to avoid problems?
There was a problem hiding this comment.
Sounds reasonable. Where would you suggest moving it to?
| synchronized (LibGraalFeature.class) { | ||
| GraalError.guarantee(singleton == null, "only a single %s instance should be created", LibGraalFeature.class.getName()); | ||
| singleton = this; | ||
| } |
There was a problem hiding this comment.
could we move the singleton initialization into the static initializer of a private static inner class? that way we don't need to do a manual synchronize and the JVM guarantees us that there is only one initialization.
There was a problem hiding this comment.
Can a feature be created and registered by some other means (e.g. search for static field or factory method) instead of by calling the default constructor? Based on my reading of com.oracle.svm.hosted.FeatureHandler#registerFeature I think the answer is no?
graalvmbot
force-pushed
the
ds/GR-60088
branch
from
8061a46 to
0f47855
Compare
…e latter instead of using a FieldValueTransformer
graalvmbot
force-pushed
the
ds/GR-60088
branch
from
0f47855 to
46bf4bb
Compare
…ndencies of jdk.graal.compiler
This PR adds the
jdk.graal.nativeimagemodule. This provides a stable API for use by libgraal that is an extension to the standard Native Image API (i.e., theorg.graalvm.nativeimage**packages here). Using this extended API,LibGraalFeature.javahas been moved intocompiler/, out ofsubstratevm/. It no longer depends on Native Image internals, allowing any GraalVM binary that supportsjdk.graal.nativeimageto be used as a tool for building libgraal. This is a step towards Project Galahad.Over time, some or all of
jdk.graal.nativeimagemay be moved intoorg.graalvm.nativeimage. This is a discussion to be had in follow-up PRs.The API changes can most easily been seen here:
A large part of the code changes comes from the fact that
LibGraalFeatureitself is now loaded in the LibGraalClassLoader which is separate from the Native Image class loader. This means the use of method handles to communicate between the "hosted" parts of libgraal (those loaded by the Native Image class loader) and the "guest" parts of libgraal has been removed. This is a large code reduction and makes the logic much easier to follow. It also means no more need for@NativeImageReinitializeas the Graal classes loaded for compiling into libgraal are different from those loaded to do the compilation and thus no longer need re-initializing.Other changes of note:
-Djdk.graal.ShowConfiguration=infohas changed (and improved) slightly to also show the SVM GC algorithm used in libgraal.Before:
Using "Graal Enterprise compiler with Truffle extensions" loaded from a PGO optimized Native Image shared libraryAfter:
Using "Graal Enterprise compiler with Truffle extensions" loaded from a Native Image shared library (PGO optimized, gc=Serial GC)--upgrade-module-pathto accelerate Truffle now needs 2 extra jars:graal-nativeimage.jarandnativebridge.jar. This will be made clearer whenpom.xmlfor the graal-js Maven demo is subsequently updated by @tzezula .FoldNodePluginclass will be deleted once [GR-60866] Use plugin class name to filter fold plugin application #10447 is merged. Ignore it.