sci 2022-10-11 | Slack Archive

didibus02:10:45

I just had a thought, kind of random, and no idea of the feasibility of this. But I was thinking, could there be a kind of Clojure runtime that starts of as sci, and then becomes full Clojure A kind of JIT, but where at first code is interpreter using sci (in a context where sci exposes all of Java), and then as functions are called or something like that, it's like replaced by real Clojure. I don't know if this even makes sense, but it's like it could allow Clojure to start fast, and then run faster. I guess maybe this could make it closer to the start.tike of Java. Though how useful that is, considering Java itself is a bit slow :man-shrugging:

lispyclouds03:10:31

The big blocker i see here is bytecode emission for it to be "real Clojure" on the JVM. SCI interprets the sexps and dispatches to the underlying code or do the side effects but has no provisions to emit something else as of now. I guess to do that we need to run SCI on the JVM itself and dispatch to the underlying things which emits bytecodes. I think that would incur similar if not more performance penalty since everything's on the JVM anyways?

didibus04:10:31

Ya I was thinking the latter, but I guess at best it would reduce the additional start time caused by Clojure itself, but wouldn't really be able to get any faster at starting than Java does itself. So maybe not a worthy effort.

borkdude06:10:20

Some people do this with native image in the cloud I believe

teodorlu20:10:03

I guess you could "record" what actions are invoked, interpret them on the fly with sci, store a list of actions and replay them on the JVM once the JVM is up and running. But then you might easily end up with running side effects twice. :thinking_face: Interesting idea, though. Do you see it used for... Servers? Any example use cases? Is it relevant to something you're working on right now?

teodorlu20:10:34

> Some people do this with native image in the cloud I believe > I'm curious about how that would happen. Is the approach just to compile the whole thing into a native image? Or does GraalVM support some kind of "gradual level up" to full JVM-like access? What part does sci play?

borkdude20:10:29

Maybe this was more like an idea than an actual implementation: but you could do a native image of a Java App for the initial responses on the cloud (fast startup) and then switch over to JVM + JIT for better performance

teodorlu20:10:33

Aaah, gotcha. Then you just start graal and JVM at the same time, and when the JVM is ready, you send traffic over to the JVM app?

borkdude20:10:17

yeah

👍 1

didibus05:10:53

Don't remember what made me think of this haha

lispyclouds13:10:49

maybe https://openjdk.org/projects/crac/ is a better solution to this!

borkdude13:10:53

I think project Leyden is also a bit about this

lispyclouds13:10:37

GraalVM being a part of OpenJDK probably changes a lot of Leyden goals i think

lispyclouds13:10:59

specially the JIT bits

borkdude13:10:53

I don't think it changes Leyden's goals, it's just one implementation of Leyden's goals

2022-10-11

Channels