You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Bertrand Delacretaz (JIRA)" <ji...@apache.org> on 2019/07/03 10:01:00 UTC

[jira] [Commented] (SLING-8556) Experiments with Sling and GraalVM native images

    [ 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)