Fork me on GitHub
#graalvm
<
2020-09-26
>
dominicm09:09:03

It seems that initialize-at-build-time is required for the hello world example, I think it was mentioned elsewhere as an optional optimization.

borkdude09:09:58

no, it's mandatory for all Clojure GraalVM programs afaik

dominicm09:09:37

https://github.com/lread/clj-graal-docs#class-initialization > For Clojure programs it is often actually feasible (unlike in a typical Java program) to change it back via --initialize-at-build-time to achieve yet faster startup time. Gave me the impression of optional. It's a bit of a pain because somehow this is causing Netty's PooledByteBuffer to be loaded at build time, which then fails. But Graal can't trace the loading class for me 🤕 This native stuff is hard

borkdude10:09:13

@dominicm You can set run time initialization per class

borkdude10:09:36

--initialize-at-run-time=<the class>

dominicm10:09:30

@borkdude the problem is that PooledByteBuffer is forced to be runtime (by the netty config), but then something which is initialized at build time, is initiailizing PooledByteBuffer. I don't know what something is, and graal can't tell me in this specific scenario.

borkdude10:09:47

ah right. sometimes this can be solved by wrapping things in a delay

dominicm10:09:57

Not my code unfortunately, it's in Lettuce.

dominicm10:09:22

I suspect Lettuce is incompatible with build time flag, and the initialization tracing doesn't work when it's loaded via the configs.

borkdude10:09:02

Maybe check https://github.com/BrunoBonacci/graalvm-clojure for similar examples that do work

dominicm10:09:09

No redis in there unfortunately, but jedis works fine :)

lread17:09:55

@dominicm I agree that the wording under that section is confusing.

lread17:09:52

@borkdude, I think we are simply trying to convey that we need to initialize at build time, but one can still defer specific classes to initialize at runtime?

borkdude17:09:40

I think that's a better wording yes, I don't know the details of why this is needed

alexmiller18:09:49

btw, Clojure 1.10.2-alpha2 has a few fixes that came from @borkdude related to reflection in case that helps y'all

borkdude18:09:32

The TCHECK one is relevant if one is going to generate random data in a graalvm native binary e.g. using spec

lread20:09:24

Thanks @borkdude and @alexmiller, I shall update our little clj-graal-docs repo!

✔️ 1
💯 1
borkdude21:09:39

@lee Why did you upload the README of clj-graal-docs to TCHECK-157?

borkdude21:09:05

hm maybe that's an automated thing when you mention the issue in a git repo?

lread21:09:49

I do have slippery fingers sometimes.. but…

borkdude21:09:29

Nice improvements btw, table of contents

lread21:09:22

oh maybe I did upload it accidentally… I was previewing the README in firefox and might have dragged it over… which… hmmm.. oops…

lread21:09:44

ya that must be it… sorry about that! Not sure how to delete it now.

borkdude21:09:30

if you hover over those files, a trash can will appear

lread21:09:13

ah had to go to jira “old view”. got it, tx!

borkdude21:09:44

there's still one left :)

lread21:09:38

got it! tx!

lread21:09:56

yeesh, I can be dangerous!

borkdude21:09:28

interesting way to promote the info in that README for sure :)

lread21:09:01

As in “may you drag and drop in interesting ways”. :-)

1
borkdude21:09:25

Pondering about an idea to leverage clojure git libs for (GraalVM or other) binaries: https://github.com/babashka/babashka.pods/issues/19