Hacker News Reader

Comment by ivanb | Hacker News Reader

If Clojure could dump the Lisp image like SBCL's save-lisp-and-die function, the startup time would be greatly reduced. I wonder if JVM itself can dump its current state and then restore execution.

Another approach to the problem would be similar to FastCGI: keep one Clojure server process running and execute scripts on it.

View on HN

> If Clojure could dump the Lisp image like SBCL's save-lisp-and-die function, the startup time would be greatly reduced. I wonder if JVM itself can dump its current state and then restore execution.

It's still hard to understand why aren't Oracle working on something like that. It's not as if they don't care about desktop at all -- JavaFX is going to be part of Java8 and they are even working on a new packaging tool-chain for it. JVM's start-up time and inability to allocate memory when needed (as compared to up-front way it's done now) are the major reasons why Java/JVM is (still) a bad solution for desktop and cli applications.

There is something like that as internal research project, but never made into the mainstream JVM.

http://java.sun.com/developer/technicalArticles/Programming/...

Interesting - that paper talks about isolates, which are implemented in Dart. Dart core team members used to work on HotSpot and other Java tech (CLDC).

"JVM's start-up time and inability to allocate memory when needed (as compared to up-front way it's done now).."

Care to elaborate? Are you saying that the JVM can't malloc()? :)

As far as mine understanding of JVM goes it works with memory in quite a different way. When JVM starts up it allocates large chunk of memory up-front (usually hundreds of megabytes) even though it doesn't really need all that memory. Usually only a part of that memory is actually used at any given moment. JVM will manage that memory with custom internal malloc/free which will allocate memory to Java objects. All this is needed to implement efficient garbage collection. See [1] for details.

Such complicated memory management is really efficient and works great for server apps. On the client -- not so much. In that case I would rather prefer a slower GC that just uses malloc/free. Why? Because from end-user perspective that's not really great when a simple app grabs a 100-200mb of memory. If all apps were like this you wouldn't be able to run many of them at the same time. (Especially on the older hardware.) Moreover for a complex JVM apps 500mb+ of allocated RAM might be a requirement. [2]

Great example of how things should work is .NET/Mono. Both of the .NET runtimes allocate memory only when it's actually needed and start-up performance is great too. All things considered JVM and CLR are very similar runtimes and there is no reason for a more client-oriented JVM implementation not to be possible.

[1] http://www.quora.com/How-does-garbage-collection-work-in-the...

[2] Eclipse for instance recommends to configure jvm to allocate at least 500mb up-front. (This is done via -Xms and -Xmx parameters.)

Sadly the JVM can't really do that (yet?). Even for normal Java applications caching the JIT would really help ramp-up time in servers.

It doesn't really buy you much since it's slower to read from disk than for the JIT to generate code on the fly.

Re: FastCGI approach. You can use Nailgun for all JVM languages: http://www.martiansoftware.com/nailgun/

Note that this addresses JVM startup overhead, but still not Clojure startup overhead (two are separate).

\ef in vimclojure uses nailgun, and it's not slow enough to notice.

Reply on news.ycombinator.com