[
https://issues.apache.org/jira/browse/SLING-8556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16877702#comment-16877702
]
Bertrand Delacretaz commented on SLING-8556:
--------------------------------------------
h2. Running a simple OSGi application as a native image created by GraalVM tools
For this first experiment I'm using my
[https://github.com/bdelacretaz/OSGi-for-mere-mortals] sample app, a very
simple standalone OSGi application, to get a feel for OSGi-related issues.
The *conclusion* is that creating a native image of an OSGi application looks
like a major effort, if that's even possible. Using the [GraalVM
agent|https://github.com/oracle/graal/blob/master/substratevm/CONFIGURE.md] to
identify the dynamic features used by my app seems to produce sensible config
files for the native-image tool, but that tool doesn't find the classes that it
needs to process at build time as they are embedded in bundles instead of being
found directly in the app's runnable jar.
h3. Details of the experiment
0) get the [https://github.com/bdelacretaz/OSGi-for-mere-mortals] code and
build it with {{mvn clean install}}
1) Naive usage of the {{native-image}} tool.
native-image -jar target/osgi-for-mere-mortals-launcher-0.0.1-SNAPSHOT.jar
-> Unsupported field java.net.URL.handlers is reachable
-> Warning: Image 'osgi-for-mere-mortals-launcher-0.0.1-SNAPSHOT' is a fallback
image that requires a JDK for execution (use --no-fallback to suppress fallback
image generation).
-> image runs but uses the GraalVM JVM, the native part just starts that,
here's the {{ps -ef}} output:
/Library/Java/JavaVirtualMachines/graalvm-ce-19.0.2/Contents/Home/jre/bin/java
-Dorg.graalvm.nativeimage.kind=fallback-executable -cp
/Users/bert/workspace/bdelacretaz/OSGi-for-mere-mortals/launcher/target/osgi-for-mere-mortals-launcher-0.0.1-SNAPSHOT.jar
ch.x42.osgi.samples.osgi101.bootstrap.OsgiBootstrap
So this is not useful, there's no reason for app startup to be faster than
usual.
2) Try the tracing agent as per
[https://medium.com/graalvm/introducing-the-tracing-agent-simplifying-graalvm-native-image-configuration-c3b56c486271]
and [https://github.com/oracle/graal/blob/master/substratevm/CONFIGURE.md], to
generate {{native-image}} config files that should allow it to work around
dynamic operations.
mkdir -p src/main/resources/META-INF/native-image
java
-agentlib:native-image-agent=config-merge-dir=src/main/resources/META-INF/native-image
-jar target/osgi-for-mere-mortals-launcher-0.0.1-SNAPSHOT.jar
Run some curl requests to activate the required code paths.
Stop with CTRL-C
-> src/main/resources/META-INF/native-image/ is populated
Rebuild with {{mvn clean install}}, the jar now contains the
{{META-INF/native-image/ files}} that {{native-image}} should use.
3) Try native-image again with these config files, embedded in our runnable jar:
native-image -jar target/osgi-for-mere-mortals-launcher-0.0.1-SNAPSHOT.jar
-> error JAR entry META-INF/native-image/jni-config.json not found
Not sure why this happens, that file is found in the jar. Give up on this
variant.
4) Move native-image config files to a different folder so that they are not
included in the jar file, and point to that path with
-H:ConfigurationFileDirectories=...
-> Error parsing reflection configuration in
/Users/bert/Desktop/META-INF/native-image/reflect-config.json:
-> Class ch.x42.osgi.samples.osgi101.app.servlets.InMemoryStorage not found
->
This makes sense as the {{InMemoryStorage}} class comes from another bundle
embedded in our runnable jar, so {{native-image}} doesn't find it on the
classpath.
At this point, give up on this experiment, it looks like fixing this would be a
lot of work.
> Experiments with Sling and GraalVM native images
> ------------------------------------------------
>
> Key: SLING-8556
> URL: https://issues.apache.org/jira/browse/SLING-8556
> Project: Sling
> Issue Type: New Feature
> Components: General
> Reporter: Bertrand Delacretaz
> Assignee: Bertrand Delacretaz
> Priority: Minor
>
> For my talk at adaptTo() 2019 I'm running a series of experiments with
> [GraalVM|http://graalvm.org], [Quarkus.io|http://quarkus.io] and Sling.
> The goal is to find out what's needed to create native images that run Sling
> components - they don't have to run a complete Sling instance but running
> things like request processing in Docker images that start quickly can be
> interesting.
> I'll use this ticket to document my experiments, feedback is welcome.
> This is just meant as a journal of my experiments, it might not be very well
> organized, I'll summarize it in the adaptTo() talk.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
