This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # babashka (68)
- # beginners (133)
- # calva (5)
- # chlorine-clover (21)
- # cider (40)
- # clj-kondo (42)
- # cljs-dev (31)
- # clojure (53)
- # clojure-austin (1)
- # clojure-europe (30)
- # clojure-italy (6)
- # clojure-nl (3)
- # clojure-uk (104)
- # clojurescript (15)
- # datascript (2)
- # datomic (50)
- # emacs (12)
- # fulcro (82)
- # graalvm (4)
- # hoplon (225)
- # jobs (4)
- # jobs-discuss (7)
- # joker (5)
- # juxt (17)
- # kaocha (13)
- # leiningen (16)
- # meander (21)
- # nrepl (18)
- # off-topic (16)
- # pathom (8)
- # pedestal (13)
- # perun (1)
- # re-frame (4)
- # spacemacs (23)
- # testing (28)
- # unrepl (3)
- # vim (5)
- # xtdb (1)
Hehe. I run out of memory trying to build a native-image of babashka using graalvm20-java8, but not graalvm19-java8. I underestimated how much RAM it takes.
I got the same on a 32GB Macbook Pro.
... Resources have been added by ServiceLoaderFeature. Automatic registration can be disabled with -H:-UseServiceLoaderFeature [bb:95710] (typeflow): 256,136.04 ms, 2.67 GB [bb:95710] (objects): 316,187.40 ms, 2.67 GB [bb:95710] (features): 7,216.23 ms, 2.67 GB [bb:95710] analysis: 583,729.52 ms, 2.67 GB [bb:95710] universe: 58,864.95 ms, 2.67 GB Fatal error: java.lang.OutOfMemoryError at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at java.util.concurrent.ForkJoinTask.getThrowableException(ForkJoinTask.java:598) at java.util.concurrent.ForkJoinTask.get(ForkJoinTask.java:1005) at com.oracle.svm.hosted.NativeImageGenerator.run(NativeImageGenerator.java:462) at com.oracle.svm.hosted.NativeImageGeneratorRunner.buildImage(NativeImageGeneratorRunner.java:357) at com.oracle.svm.hosted.NativeImageGeneratorRunner.build(NativeImageGeneratorRunner.java:501) at com.oracle.svm.hosted.NativeImageGeneratorRunner.main(NativeImageGeneratorRunner.java:115) Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded Error: Image build request failed with exit status 1 com.oracle.svm.driver.NativeImage$NativeImageError: Image build request failed with exit status 1 at com.oracle.svm.driver.NativeImage.showError(NativeImage.java:1527) at com.oracle.svm.driver.NativeImage.build(NativeImage.java:1289) at com.oracle.svm.driver.NativeImage.performBuild(NativeImage.java:1250) at com.oracle.svm.driver.NativeImage.main(NativeImage.java:1209)
not quite sure what you're asking, but sometimes i find lein clean can help between compilations
@U0ETXRFEW i had success building with 20 -- though it helped here to do:
export BABASHKA_XMX="-J-Xmx25g" before running the build
No, I actually tested to build babasska master with graal 20 as my java dist, not my GRAALVM_HOME... Rebuilding now.
in one run, it took a really long time (and i don't recall if it worked in the end) and it was 14 then
graalvm always defaults to 14g. please test with the newest dev build: https://github.com/graalvm/graalvm-ce-dev-builds/releases if that doesn't work, we'll have to make an issue
It's taking forever here. Think it will end the same way as it did with the nrepl branch.
but of course, I forgot to update my submodules when switching to master. I am not constructed for these kinds of exercises! 😃
But maybe that is for the good and can help isolate the problem. Or at least rule out one source as the problem.
Out of memory buidling master. WIth sci from the nrepl branch. Updating that now and will test again. Then I need to go work for food.
when i scroll back, i see that the really long compilation that ultimately failed for me was nrepl-server with graal 20.0.0 java 8. there are two
-Xmx options in the invocation. the later one is
-Xmx3g which i presume wins.
-Xmx7g works too, so it seems possible that this might work on the VPS machine mentioned earlier
it does seem to take somewhat longer with less memory, but at least it appears possible
Btw if you want to test the bb nREPL without building a native image first, you can also run it via the JVM, e.g.: lein bb
Bumping memory to 4gb didn't work on circleci: https://circleci.com/gh/borkdude/babashka/5262 😕
@marc-omorain I though you bumped memory on my account to 6 or 7gb, at least this is what I saw for some time?
hmm, I think graalvm 20 may have another issue btw. the binary is around 8mb bigger on v20. [email protected] 1 borkdude staff 49647716 Mar 23 11:06 bb