Discuss GraalVM related topics. Use clojure 1.10.2 or newer for all new projects. Contribute to and GraalVM slack:
chrisn 2021-06-29T15:00:29.238200Z

I think this also relates to clojure startup time. Perhaps we attempt a clojure-side compilation flag that solves (or makes progress towards) both issues at AOT time?

chrisn 2021-06-29T15:01:16.238400Z

meaning when this flag is in effect the clojure compiler generates different byte code and this byte code both starts up faster and works with graal native without needing --initialize-at-build-time.

borkdude 2021-06-29T15:04:15.238600Z

@chris441 do you have any concrete ideas of what can be done differently?

chrisn 2021-06-29T15:04:34.238800Z

Not without more careful consideration I do not.

borkdude 2021-06-29T15:05:06.239Z

what Clojure does in static initializers is resolve vars, load classes, etc.

borkdude 2021-06-29T15:05:25.239200Z

delaying the class loading to run time won't work in a native image

chrisn 2021-06-29T15:05:27.239400Z

I will look a lot more closely; I just know those are two related things and my profilers always show var initialization as one of the startup issues so somehow compiling that data down into something perhaps more concrete that loads faster is an interesting issue that seems related.

chrisn 2021-06-29T15:05:38.239600Z

Also interesting for dalvik.

chrisn 2021-06-29T15:06:03.239800Z

I know this is an area smart people have looked at before.

borkdude 2021-06-29T15:06:08.240Z

delaying var initialization to build time will make native images slower to start up right?

chrisn 2021-06-29T15:06:48.240200Z

I don't want to delay anything, I want AOT to produce data as a side effect that can be quickly loaded to initialize vars during runtime initialization.

borkdude 2021-06-29T15:07:34.240400Z

ok, but now these are are already initialized in the image heap, so that work has already been done when starting the image

chrisn 2021-06-29T15:07:35.240600Z

Exact opposite of delaying.

borkdude 2021-06-29T15:11:10.240800Z

My point is: moving work from build to run time makes things slower

chrisn 2021-06-29T15:11:31.241Z

Well, for example in your javap above:

const__0 = RT.var("clojure.core", "println");

chrisn 2021-06-29T15:12:27.241200Z

Yes, I agree and that is not what I am suggesting. const_0 being initialized to a static class instance in your example above would make things faster as it would bypass the RT.var mechanism.

borkdude 2021-06-29T15:13:11.241400Z


borkdude 2021-06-29T15:13:41.241600Z

it could directly reference the AOT-ed class which represents the println var right?

chrisn 2021-06-29T15:16:14.241800Z

Yes, in this case. You also have the case where something is initialized via a complex function that produces a persistent datastructure and in this case the data can be saved in resources and found via a hashtable lookup or straight array lookup in constant time eliding the generating code. I haven't looked at this in huge depth but for instance I was extremely careful with dtype-next and it still takes some time even after an AOT run to pull in, for instance, the ND system via require. This is a solvable problem.

chrisn 2021-06-29T15:17:43.242Z

My thought is more of the form move --initialize-at-build-time into the clojure compiler and allow anything that it did in the graal vm system to be done during the AOT step. Then --init-at-build-time should be a noop if done during graal vm compilation.

borkdude 2021-06-29T15:17:59.242200Z

As clojure.core is AOT-ed by default anyway, I guess Compiler could be instrumented in such a way that it can reference these classes directly when generating more code. For core vars only it would already be a win

chrisn 2021-06-29T15:18:45.242500Z

This is complicated by the fact that bytecode files aren't general data storage mechanisms (at least as far as I know) which means you need some level of sidecar file generated at build time for pure data.

borkdude 2021-06-29T15:18:56.242700Z

The Compiler could keep track of what vars map to which classes

chrisn 2021-06-29T15:19:20.242900Z

It would be nasty and error prone. Definitely a YMMV pathway but with time it could work well.

chrisn 2021-06-29T15:20:02.243100Z

If it opened up both simpler Graal native and more dalvik development that would IMO be a very solid win worth real invesment.

chrisn 2021-06-29T15:21:11.243300Z

Well, I guess if nubank agrees it may be worth real invesment 🙂.

borkdude 2021-06-29T15:43:33.243500Z

What problems does Dalvik currently have with Clojure?

borkdude 2021-06-29T15:44:08.243700Z

I'm seeing that Dalvik is now replaced with something else

borkdude 2021-06-29T15:45:14.243900Z

maybe just a detail. Does ART (Android Runtime) interpret Java bytecode directly?

chrisn 2021-06-29T16:11:12.244100Z

I am referring to this article:

chrisn 2021-06-29T16:11:15.244300Z

borkdude 2021-06-29T16:16:09.244500Z

Interesting article, thanks for sharing