This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-11-23
Channels
- # announcements (5)
- # beginners (14)
- # bigdata (1)
- # calva (13)
- # cider (10)
- # clj-kondo (53)
- # cljs-dev (1)
- # cljsrn (12)
- # clojure (67)
- # clojure-uk (8)
- # clojuredesign-podcast (3)
- # clojurescript (53)
- # duct (4)
- # emacs (1)
- # events (1)
- # figwheel-main (5)
- # fulcro (9)
- # graalvm (68)
- # graphql (3)
- # joker (3)
- # juxt (4)
- # off-topic (32)
- # other-languages (1)
- # pathom (35)
- # re-frame (6)
- # rum (1)
- # shadow-cljs (52)
- # spacemacs (3)
- # sql (10)
- # tools-deps (15)
has anyone had trouble compiling with native image getting this error:
ERROR! Error: Main entry point class 'app.server-main' not found.
com.oracle.svm.core.util.UserError$UserException: Main entry point class 'app.server-main' not found.
@mattsfrey maybe you need to write app.server_main
?
..although now it’s been building at max cpu+mem usage for like 15+ mins with no end in sight 😒
going to take the dog on a long walk and see if the build ever finishes, after that if it was actually successful I’ll try running it in a container to try and isolate thing
@mattsfrey @lee has a similar issues just with compiling clojure.test.
So far I've had luck with smallish command line apps and a Clojure interpreter which is tweaked to be graalvm friendly
@mattsfrey It's mostly about avoiding reflection and avoiding CLJ-1472
it's probably easier to start small and then build up, so you can see where it trips up graalvm
I’d have freed up some ram if I had known it was this bad, using like 3.6 wired and 7gb swap atm
no I had a ton of other crap open though, multiple intellij windows, bajillion chrome tabs etc
just added a tip in our repo for RAM usage: https://github.com/lread/clj-graal-docs#native-image-ram-usage
not sure what target OSes you are trying to build for... if linux only drone cloud might be an option as it has 64gb RAM available for build.
feel free to ask more questions, but also.. please consider contributing anything you learn to our repo: https://github.com/lread/clj-graal-docs
mostly experimenting with this to lower the memory footprint clojure microservices use in prod, if the builds require non trivial ram and take huge amounts of time this probably isn’t a feasible option
that's also my rule of thumb: if it doesn't compile under 2 minutes with 3gb of ram, it's probably not going to work out well
i’ll spend more money on build costs than the savings in server ram ultimately once hooked to ci/cd lol
max out your RAM as big as you can to start... my stuff compiled in 3 minutes with 16gb an, 11 minutes with 8gb and failed with 4gb with out of memory after 1 hour.
I think trying to get a clean container with minified classpath and all that and then tweaking ram options might help, will have to see
I’ve been also looking at some clojure-to-go compilers but they seem pretty half baked
here's my drone cloud config, if you need a sample: https://github.com/lread/rewrite-cljs-playground/blob/master/.drone.yml. Note that my goal for this was to just run my tests after natively compiled by GraalVM.
it finally finished! ERROR! Fatal error: java.lang.OutOfMemoryError: Java heap space
throwing 24GB at it on my work station with 8 cores, will have to see how this goes
I think regardless this build process is going to be way too heavyweight for a while to use with production deployments
seems like its mostly useful for cli tools you can build and distribute binaries of
I would like to do another test on linux and see if that makes a difference vs running on osx
having to allocate 512mb ram per instance kind of kills using clojure in a microservice arch if you’re on a slim budget
probably going to just stick to monolithic backends because I’m loathe to write in a different language at this point
@mattsfrey the tradeoff between graalvm native and a normal JVM is usually latency vs throughput. the JVM is optimized for throughput
for example, linting thousands of files with clj-kondo is faster on the JVM than with the native version of clj-kondo, but linting a single file is faster with the native version, because of the startup time
yeah, that's also one benefit of it. there are some Java microservice projects doing this with GraalVM, you could maybe explore those
but it's maybe also good to not start with a huge framework to compile graalvm. I can imagine that just compojure + jetty could compile fine maybe
yeah that’s the other thing — I picked a super bulky framework with a huge ammount of deps to start with
I have a relatively simple webapp here: https://github.com/borkdude/who-follows-me/blob/master/src/who_follows_me/handler.clj