[native-image] java out of memory error

[hugsyy]

Hello,
I am trying to build a native image with following Dockefile:

FROM oracle/graalvm-ce:1.0.0-rc11 AS graal
COPY . /app
WORKDIR /app
RUN javac ExtListDir.java  
RUN native-image \ 
         -H:+ReportUnsupportedElementsAtRuntime \
         --static \
	 --language:js \
         ExtListDir
	
FROM scratch
COPY --from=graal /app/extlistdir /app
CMD ["/app"]

And I get java out of memory error. The java program is from demo examples here - https://github.com/graalvm/graalvm-demos/blob/master/native-list-dir/ExtListDir.java

[cstancu]

@hugsyy how much memory do you give to your docker container? You will need at least a few GB to build a js image.

[hugsyy]

@cstancu Thank you, I changed docker memory limit and it worked.

[hugsyy]

@cstancu I can successfully build native image now but when I run it I get this error:

Exception in thread "main" java.lang.NullPointerException
        at com.oracle.graalvm.locator.DefaultHomeFinder.getGraalVmHomeFallBack(DefaultHomeFinder.java:343)
        at com.oracle.graalvm.locator.DefaultHomeFinder.getGraalVmHome(DefaultHomeFinder.java:263)
        at com.oracle.graalvm.locator.DefaultHomeFinder.getHomeFolder(DefaultHomeFinder.java:130)
        at com.oracle.graalvm.locator.GraalVMLocator.collectClassPath(GraalVMLocator.java:60)
        at com.oracle.graalvm.locator.GraalVMLocator.getLanguagesLoader(GraalVMLocator.java:99)
        at com.oracle.graalvm.locator.GraalVMLocator.locate(GraalVMLocator.java:160)
        at com.oracle.truffle.api.impl.TruffleLocator.initializeNativeImageTruffleLocator(TruffleLocator.java:115)
        at com.oracle.truffle.api.impl.Accessor.initializeNativeImageTruffleLocator(Accessor.java:98)
        at com.oracle.truffle.polyglot.VMAccessor.initializeNativeImageTruffleLocator(VMAccessor.java:71)
        at com.oracle.truffle.polyglot.PolyglotImpl.buildEngine(PolyglotImpl.java:178)
        at org.graalvm.polyglot.Engine$Builder.build(Engine.java:488)
        at org.graalvm.polyglot.Context$Builder.build(Context.java:1085)
        at org.graalvm.polyglot.Context.create(Context.java:663)
        at ExtListDir.main(ExtListDir.java:11)

I made a slight change to the Dockefile btw:

FROM oracle/graalvm-ce:1.0.0-rc11 AS graal
COPY ./ExtListDir.java /usr
WORKDIR /usr
RUN javac -cp java/default/jre/lib/boot/graal-sdk.jar ExtListDir.java  
RUN native-image \ 
    -H:+ReportUnsupportedElementsAtRuntime \
    --static \
    --language:js \
    ExtListDir

FROM scratch
COPY --from=graal /usr/extlistdir  /app
CMD ["/app"]

[shelajev]

Yeah, the NPE looks like a bug. As a temporary workaround, can you please move the /app from the root. Something like could work (worked on my machine).

COPY --from=graal /usr/extlistdir  /usr/app
ENTRYPOINT ["/usr/app"]

[shelajev]

Also, I don't think you need -cp java/default/jre/lib/boot/graal-sdk.jar , javac from the GraalVM has that automatically.

[shelajev]

And for the record, I managed to build this image by giving Docker 6GB. 4GB didn't work (got OOM).

[cstancu]

@tzezula can you please take a look at the NPE above? Thanks!

[hugsyy]

@shelajev Thanks! Workaround worked for me too.

[tzezula]

The NPE is a bug, I will fix it.
The problem happens when Truffle tries to find a GraalVM home for the "app" which is in root directory. Workaround is moving the app into folder.

[eraserhd]

I'm running out of memory attempting to generate a native image on Circle CI (containers have 4G). It looks like memory is hard-coded for the native-image server to something like 6G? It appears to accept -J options, but if I try to give it -J-Xmx3G, it removes that. Is there a trick to it?

[tzezula]

The NPE is fixed for rc12: 62872b7

[cstancu]

Thank you, @tzezula!

[cstancu]

@eraserhd there is no trick to it. That seems to be a bug, we'll look into it. You can run with --no-server to avoid using an image-build server. Then -J-Xmx3G should be correctly interpreted.

[olpaw]

This is not a bug. In server-mode we allow 80% of the memory that is physically available on the machine to be used for image building (if needed), thus we ignore any Xmx hits (either provided by native-image.properties files or by -J-Xmx args) because we allow using almost all physically available ram anyway.

[cstancu]

@olpaw thanks for the explanation. @eraserhd we will document this behavior to avoid confusion in the future.