graalvm

Discuss GraalVM related topics. Use clojure 1.10.2 or newer for all new projects. Contribute to https://github.com/clj-easy/graal-docs and https://github.com/BrunoBonacci/graalvm-clojure. GraalVM slack: https://www.graalvm.org/slack-invitation/.
2020-03-21T16:27:54.348Z

Hey there, I created my first tool using GraalVM πŸŽ‰ https://github.com/jorinvo/prometheus-pushgateway-cleaner The usecase is pretty specific but I thought the setup might be interesting for others to look at :) The tool is intended to run in a Docker container and I keep it running constantly that’s why having low memory overhead is nice. The Docker image is built and deployed automatically through a Github Action. Also, the project uses tools.deps and not lein. The trickiest part was that first I wanted to pack the binary in a FROM scratch or plain Alpine container. But the DNS lookup of clj-http-lite failed. So instead I am using an Alpine image with glibc included now. I also tried using https://github.com/gnarroway/hato because I was hoping to use the Java 11 HTTPClient, but here Graal doesn’t even compile. (It fails with an error that seems to be coming from clojure.spec… Error: unbalanced monitors: mismatch at monitorexit ) Maybe someone knows a way to do HTTP calls in a GraalVM binary in a FROM scratch Docker image πŸ™‚

1πŸ‘
katox 2020-03-23T10:01:37.354100Z

@hi895 the simplest way is to build within the docker container and copy the DNS dynamic .so

katox 2020-03-23T10:01:44.354300Z

Have a look at this https://github.com/leafclick/pgmig/blob/master/Dockerfile

2020-03-23T10:20:58.354600Z

Thanks @katox! That looks interesting πŸ™‚ For now I think I stick with the alpine-glibc approach but if the image size is really critical, that is definitely a neat solution!

katox 2020-03-23T10:22:03.354800Z

Dev image size is critical? While building? Because this target image really just contains the shared libraries and the final graal native binary, nothing else.

2020-03-23T10:26:41.355Z

I meant, copying all the shared libraries is a great solution to get a small FROM scratch image. With alpine the image is probably a little bigger. The reason for me to still stick with alpine for now is simply that the Dockerfile has less lines of code and feels easier to maintain.. but it’s really cool that all it takes to run from scratch is copying those libraries πŸ™‚

katox 2020-03-23T12:50:59.355200Z

Note that it is not totally safe to build a graal image on one system and run it against shared libraries of another. Slight incompatibilities or memory corruption would be hell to debug. Unfortunately you can't use static linking if you need DNS resolving.

2020-03-23T13:36:19.355400Z

hm I do use --static … https://github.com/jorinvo/prometheus-pushgateway-cleaner/blob/master/deps.edn#L22 or you refer to something else?

katox 2020-03-23T14:21:50.355700Z

Yes, you can't use static linking, therefore -static. See https://github.com/oracle/graal/issues/571

2020-03-23T14:28:31.356Z

Interesting, because that is not the issue I get. I use --static . DNS lookup works as long as glibc is included in the final image. If glibc is not included, I also don’t get a SEGFAULT. I get a UnknownHostException.

katox 2020-03-23T14:30:56.356200Z

Yes, it is in the linked issues, see https://github.com/oracle/graal/issues/1151

1πŸ‘Œ
2020-03-23T14:33:45.356500Z

Yes, that is exactly the issue I also came across πŸ™‚

katox 2020-03-23T14:42:10.356800Z

I talked about the issue with Oracle guys. In the end they marked the whole "static linking with glibc" as an usupported case. Not just by them but GNU as well. So I ended up with something that's more or less the same for me minus some initial hunting of dynamically linked shared libraries. But if you stick with a stable distribution like stable debian they are very unlike to ever change.

2020-03-23T14:50:08.357Z

That sounds like a good compromise, yes πŸ™‚ Sad to hear the don’t plant to support this πŸ˜• The easy of creating static binaries is something I miss from writing Go πŸ˜‰

2020-03-21T16:31:26.348300Z

also thank you @borkdude for #babashka! The project is a great resource for graal stuff :)

borkdude 2020-03-21T16:31:58.348700Z

@hi895 Error: unbalanced monitors: mismatch at monitorexit => 1.10.2-alpha1 fixes that

borkdude 2020-03-21T16:32:28.349300Z

this is a compatible version of hato: https://github.com/borkdude/hato - but compilation takes long (8 minutes)

borkdude 2020-03-21T16:32:52.349600Z

np πŸ™‚

2020-03-21T16:35:13.350Z

That’s awesome! Thank you πŸ™‚ But 8 minutes compilation time is a πŸ™ˆ For that I rather use the little bit bigger Docker image πŸ˜„

borkdude 2020-03-21T16:36:07.351Z

@hi895 depending on what you need to do with http, babashka is leaning more towards this approach these days: https://github.com/borkdude/babashka.curl

borkdude 2020-03-21T16:36:35.351700Z

"just use curl" with a sprinkle of clojure.

2020-03-21T16:38:38.351900Z

clj-http-lite works fine for my usecase I was just hoping to find a way to run FROM scratch . Requiring curl doesn’t help toward that goal. The current 17mb image is small enough though I guess πŸ™‚

borkdude 2020-03-21T16:39:03.352100Z

right πŸ™‚

borkdude 2020-03-21T16:39:36.352300Z

I don't fully get what this tool is about, but I love that you made something and it worked for you

2020-03-21T16:42:29.352500Z

yes, really cool that this works πŸ™‚ The usecase is very specific, yes πŸ˜†

2020-03-21T16:46:08.352700Z

I am curious which part of hato was not compatible? It seems like for me the normal hato just compiled and the Docker image runs. Compilation time was 480,528.08 ms btw πŸ˜„

borkdude 2020-03-21T16:46:56.352900Z

It has conditional requires.

borkdude 2020-03-21T16:47:23.353100Z

yeah, that's what I said, 480s = 8 minutes πŸ™‚

1πŸ˜‚
2020-03-21T16:55:56.353400Z

ok, unfortunately hato does have the same problem that DNS resolving doesn’t work in a from scratch image.. so I will stick with the current solution πŸ™‚