Discuss GraalVM related topics. Use clojure 1.10.2 or newer for all new projects. Contribute to and GraalVM slack:
dharrigan 2020-06-09T14:01:15.321500Z

I'm eventually getting round to trying to see if I can convert a very small application to run natively. However, I'm observing a huge amount of time to produce and the native image compliation fails with java.lang.OutOfMemoryError: GC overhead limit exceeded

dharrigan 2020-06-09T14:05:39.321800Z

Giving the native image maker more gigs...

dharrigan 2020-06-09T14:08:59.322Z

that helped 🙂

avi 2020-06-09T14:48:43.323200Z

I recently encountered those issues as well. Have you seen this repo? There are a bunch of useful tips:

avi 2020-06-09T14:49:13.323700Z

Check out the tip on direct linking

avi 2020-06-09T14:50:07.325300Z

And also see if there’s anything you can prune from your dependency tree. I removed core.async and its deps and my compile times (and the ram required) dropped substantially.

borkdude 2020-06-09T15:01:11.325600Z

hmm babashka does include core.async but I never noticed a problem with that

dharrigan 2020-06-09T15:10:33.325800Z

Yes, I'm using the clj-graal-docs as a reference

dharrigan 2020-06-09T15:11:09.326400Z

Unfortunately, I've had t ostop, as I'm getting far too many problems with messages such as these io.netty.buffer.AbstractByteBufAllocator the class was requested to be initialized at run time (from the command line). io.netty.buffer.AbstractByteBufAllocator has been initialized without the native-image initialization instrumentation and the stack trace can't be tracked. Try avoiding to initialize the class that caused initialization of io.netty.buffer.AbstractByteBufAllocator

dharrigan 2020-06-09T15:11:30.326800Z

(due to 3rd party library dependencies)