6 years of professional Clojure

I’m not as familiar with this. How does it differ from pre-compilation like say what GraalVM native compilation does? Are we talking a memory dump that can be reloaded into an offset memory?

I wonder if one could compile remotely. Imagine a remote REPL where the code is read and compiled on the client, then sent to the server to simply be loaded and evaluated. Especially with a cross-compiler, could this be a way to maintain the program lean on the running machine by offloading the compilation to another?

To be explicit, I’m not comparing Lisps vs Others, I’m simply trying to compare different runtime models and using known ones as examples. I think in the Lisp world, there’s probably examples of quite a lot of those models if you go looking for them.

I’m not as familiar with this. How does it differ from pre-compilation like say what GraalVM native compilation does? Are we talking a memory dump that can be reloaded into an offset memory?

The idea is “image based development.” In common lisp and predecessors (unsure about racket, but I think something similar) and small talk (very famous for it), you basically get your running “World” e.g. the repl into a state you want, then you can dump it as an image. For sbcl this ends up being an executable image. So one common deployment process e.g. for apps, is to just load up everything (also loading from FASLs which are precompiled libs) so that all the packages (namespaces) are setup and the the app (e.g. a main invocation) is ready to run or is defined. Then you save the image and have basically an instantly (relative) loadable lisp environment. Basically a form of AOT compilation, except you are building a deployable environment that can be invoked as a binary with no extra lisp-side runtime requirements like compiling or eval’ing or loading (the OS is just loading an executable), with the caveat that you can still mess with the image e.g. provide a repl and eval (comple stuff) after the fact. You’re just “resuming” the repl state when the executable is invoked.

Imagine a remote REPL where the code is read and compiled on the client, then sent to the server to simply be loaded and evaluated.

Interesting idea. Lean “runtime”, leave the compiler on the server, dynamically load updates over the wire (assuming a decent trust model). Sounds kind of like Erlang’s code distribution and hot swapping functionality.

Can those images be restored on a different machine afterwards?

Also I think the word “dump” isn’t detailed enough for me. Like would it simply take all the compiled forms to this point (even those with no corresponding source), and bundle it? Or will it also dump heap and other memory in a way that it can restore back into memory?

That is the point. With respect to possible architecture/os differences (emitted code is assembly specific to your hardware and os), so you have to build on different platforms (I believe there are CI pipelines to do this) as you would with e.g. native-image. There are some tricks around foreign/shared libs from the host system, but there are work arounds and additional libraries/application builders that can statically link and bundle everything together.

Or will it also dump heap and other memory in a way that it can restore back into memory?

Heap is saved. Good overview from Rainer Joswig

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.