Hacker News Reader

Comment by praptak | Hacker News Reader

For me the most interesting part is how it gets rid of the JVM startup time.

So there are two parts to the solution: The first part is Small Clojure Interpreter (sci) which is a "(subset of) Clojure written in Clojure", so kind of McCarthy for Clojure. A cool project in itself but it still needs a VM to run.

So here is where the second part comes in: the GraalVM produces native binaries from various things, including Clojure code and SCI is simple enough to work with GraalVM.

It's cool how these two pieces of tech combine together to create something greater than the sum of the parts.

View on HN

The startup time of the jvm is negligible. This myth keeps coming up. Most of the startup time is Clojure itself.

This high startup time in Clojure is a side-effect of the JVM. If you have a hello world program that does nothing it is indeed fast.

If you are running Clojure you need to run at least clojure.core. Loading that is handled - surprise - by the JVM. As would be expected, if you run other implementations (like Dalvik), this can change dramatically (for worse, usually).

So it is correct that loading the JVM itself is not what's taking most of the time. But loading take so much time because of the JVM.

https://blog.ndk.io/clojure-bootstrapping.html

Whenever "Clojure startup time" comes up, people are quick to point to one thing: either it's the JVM "bloat," or that it's nothing to do with the JVM and is actually all Clojure.

Here's a pretty good (if a bit outdated) analysis on Clojure startup time: http://clojure-goes-fast.com/blog/clojures-slow-start/

The question is, could Clojure be rewritten in a way that loads significantly faster with the same behavior on the JVM? I'm not sure.

And especially on big projects, the lack of DCE on the JVM can lead to loading a ton of useless code that significantly impacts startup time outside of the Clojure language.

A slightly simpler explanation: GraalVM solves the startup time but clojure's built-in eval wouldn't work after compilation so you need to reimplement it in a simpler way.

Are you certain that’s the case?

See: https://github.com/BrunoBonacci/graalvm-clojure#readme

That's a table of library compatibility w/ GraalVM, one reason for incompatibility can be use of runtime evaluation.

I think it's related to dynamic loading of classes (and since Clojure functions get compiled to classes, this might be the issue), not really evaluation per se. But I haven't really looked at Graal native image for a while, so I'm not sure what's the current status.

Reply on news.ycombinator.com