Are there any Java VMs which can save their state to a file and then reload that state?

Question

Are there any Java VMs which can save their state to a file and then reload that state?

If so, which ones?

Answer 1

Another option, which may or may not be relevant in your case, is to run the JVM (any JVM) inside a virtual machine. Most virtual machines offer the option to store and resume state, so you should be able to restart your PC, fire up the VM when it comes back up and have the Java process pick up from where it was.

I use VMWare Player for testing on IE at work, and this works as noted above when I close and later reopen it. I don't generally do this when apps are doing anything of note in the VM, but as long as they aren't accessing any external resources (e.g. network sockets), I would expect it to work as if the VM was never shut down.

Answer 2

Continuations are probably be what you are looking for:

[...] first class continuations, which are constructs that give a programming language the ability to save the execution state at any point and return to that point at a later point in the program.

There are at least two continuation libraries for Java: RIFE continuations and javaflow. I know that javaflow at least allows serializing state to disk:

A Continuation can be serialized if all objects it captured is also serializable. In other words, all the local variables (including all this objects) need to be marked as Serializable. In this example, you need to mark the MyRunnable class as Serializable . A serialized continuation can be sent over to another machine or used later. - Javaflow Tutorial

Answer 3

You should serialize relevant domain-specific objects which can be de-serialized by another JVM run-time.

I'm not aware of any tools persisting an entire JVM. The closest I got to doing this was creating a core dump from a running JVM process using gcore, then using jsadebugd, jmap or jstack to debug it.

For instance:

$ jps # get JVM process ID XXX
$ gcore -o core XXX
$ jsadebugd $JAVA_HOME/bin/java core.XXX

UPDATE

I don't think you're going to find a solution that's portable between architectures just yet.

Answer 4

It is worth noting that many objects cannot be serialized as they have state outside the java context. e.g. Sockets, Threads, Open files, Database connections. For this reason, it is difficult to to save the state of a useful application in a generic way.

Answer 5

I'm not aware of JVM's that can store state. Depending on your exact needs, you can maybe consider using Terracotta. Terracotta is essentially able to share heap state between JVM's, and store this state to disk.

This can be used to cluster applications, and/or make the heapstate persistent. In effect, you can use it to start the JVM up and pick up where you left off. For more information check out: http://www.infoq.com/articles/open-terracotta-intro

Hope this helps.

Answer 6

I've worked on an embedded Java project which used this approach to start up quickly. The JVM was from Wind River, running on top of VxWorks.

Answer 7

Sun has done some research on "orthogonal persistence", which provides "persistence for the full computational model that is definedby the Java Language Specification":

http://research.sun.com/forest/COM.Sun.Labs.Forest.doc.opjspec.abs.html

PJama is a prototype implementation:

http://research.sun.com/forest/opj.main.html

Answer 8

To my knowledge, there is nothing to capture JVM state and restore it, but people are trying to serialize/deserialize the Thread class to achieve something similar. The closest thing to a working implementation I found was brakes, but you may find more when you google for "thread serialization".

Answer 9

I take it you want to be able to resume from where the snapshot was stored, as if nothing thereafter had happened.

I wonder how many framework components and libraries such functionality would break. Suddenly, you are reviving a JVM state from storage; in the meantime, the clock has mysteriously skipped forward by 23 hours, network connections are no longer valid, GUI objects no longer have any underlying O/S handles... I'd say this is nontrivial, and impossible in the general case without modifying the framework extensively.

Answer 10

If you can get away with just storing the state of your in-memory objects, then something like Prevaylor might work for you. It uses a combination of journalling changes to business objects with a serialized snapshot to record the state of your objects, which you can then reload later.

However, it doesn't store the full JVM state (call stack, GC status etc). If you really need that level of detail, then a specialized JVM might be needed.

Answer 11

The answer at this time is no, there are no JVMs that can 'hibernate' like your operating system can or like VMWare et al can.

You could get half-way there, depending on the complexity of your app, by just serializing state out when the program closes and serializing it back in, but that won't do stuff like pause executing some business logic when you close and then continue when you open it again.