Experiment: Native Image

[lorenzleutgeb]

With the release of Oracle GraalVM it is possible to compile Java code to x86-64 executables. It would be nice to have the possibility to distribute/run Alpha as a single binary. Currently, the benefits are limited (no startup time) and the runtime is still being optimized.

In a different project I am working on I had some quick success with Graal's native-image compiler, so I went ahead and tried this out with Alpha, but ran into a limitation of Substrate VM (part of the Graal ecosystem):

Build on Server(pid: 28439, port: 26682)
   classlist:     634.46 ms
       (cap):     419.99 ms
       setup:     572.45 ms
    analysis:   4,389.93 ms
Error: Must not have a FileDescriptor in the image heap.
Trace:  object java.io.FileOutputStream
    object ch.qos.logback.core.recovery.ResilientFileOutputStream
    object ch.qos.logback.core.FileAppender
    object ch.qos.logback.core.status.InfoStatus
    object java.lang.Object[]
    object java.util.ArrayList
    object ch.qos.logback.core.BasicStatusManager
    object ch.qos.logback.classic.LoggerContext
    object ch.qos.logback.classic.Logger
    method at.ac.tuwien.kr.alpha.solver.ArrayAssignment.recordAssignment(int, ThriceTruth, NoGood, int, ArrayAssignment$Entry)
Call path from entry point to at.ac.tuwien.kr.alpha.solver.ArrayAssignment.recordAssignment(int, ThriceTruth, NoGood, int, ArrayAssignment$Entry): 
    at at.ac.tuwien.kr.alpha.solver.ArrayAssignment.recordAssignment(ArrayAssignment.java:318)
    at at.ac.tuwien.kr.alpha.solver.ArrayAssignment.assignWithDecisionLevel(ArrayAssignment.java:257)
    at at.ac.tuwien.kr.alpha.solver.ArrayAssignment.assign(ArrayAssignment.java:177)
    at at.ac.tuwien.kr.alpha.solver.WritableAssignment.assign(WritableAssignment.java:60)
    at at.ac.tuwien.kr.alpha.solver.DefaultSolver.close(DefaultSolver.java:235)
    at at.ac.tuwien.kr.alpha.solver.DefaultSolver.tryAdvance(DefaultSolver.java:161)
    at at.ac.tuwien.kr.alpha.solver.AbstractSolver$1.tryAdvance(AbstractSolver.java:31)
    at java.util.Spliterator.forEachRemaining(Spliterator.java:326)
    at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)
    at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:496)
    at com.oracle.svm.core.option.SubstrateOptionsParser.parseOption(SubstrateOptionsParser.java:241)
    at com.oracle.svm.core.option.RuntimeOptionParser.parseOptionAtRuntime(RuntimeOptionParser.java:168)
    at com.oracle.svm.core.option.RuntimeOptionParser.parse(RuntimeOptionParser.java:138)
    at com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:183)
    at Lcom/oracle/svm/core/code/CEntryPointCallStubs;.com_002eoracle_002esvm_002ecore_002eJavaMainWrapper_002erun_0028int_002corg_002egraalvm_002enativeimage_002ec_002etype_002eCCharPointerPointer_0029(generated:0)

Error: Processing image build request failed

In brief: Some "static" code, attempts to open a file which is not possible in this setting. It's the logging framework.

Apart from our dependencies, the actual code implementing Alpha should be quite straightforward to compile.

[madmike200590]

Update: While doing performance tests for issue #75, I had the same idea and tried the same thing with the latest graal version. Problem is still logback, but I got the standalone image working with --ignore-missing-classpath flag. Unfortunately the image isn't much use because while everything works fine, since one of the logback configurer classes is broken by the image (I'm assuming because of some unsupported "reflection magic" being used), the loglevel defaults to debug, causing way too much output for performance to be anywhere near acceptable. What I found interesting is that the problem is really logback, but not slf4j, so it might be worth a try switching over to log4j or some simpler slf4j-supported thing for the purpose of image creation

(EDIT: sorry for spam, I wanted to comment, not close the issue...)