views:

804

answers:

11

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

If so, which ones?

+2  A: 

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.

opyate
+2  A: 

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.

starblue
+6  A: 

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.

Andrzej Doyle
+2  A: 

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".

Marvin
+1  A: 

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.

Peter Lawrey
A: 

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

Kjetil Ødegaard
+1  A: 

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.

KarstenF
+3  A: 

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.

Rolf
+1  A: 

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

waqas
Dalma (https://dalma.dev.java.net/) apparently does continuations as well.
Sean Reilly
Continuations are cool and all, but only work within a running process to save some piece of work for later while going on to do other stuff. The question seems to be about resetting the program and JVM to an earlier state (possibly with an intervening shutdown).
Pontus Gagge
@Pontus Gagge: You didn't read the second quote. javaflow continuations serialize the stack and everything. They are reloadable from disk later. Even on a different machine.
waqas
+1  A: 

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.

Pontus Gagge
Those are the same problems faced by your OS hibernating or a VM server pausing a VM, presumably they would handled, or more accurately not handled, the same way.
SCdF
...with the difference that the O/S and driver stacks actually know about the hibernation and can pack/unpack things appropriately. Here, a process happening to contain the JVM just becomes amnesiac and expects everything to work...
Pontus Gagge
This is exactly what happens when I close my laptop lid - The computer goes to sleep. I open the laptop lid and the apps continue where they left off. Yes, if I have a socket open at the time I close the lid then the socket is closed. the VM should be no different.
jdkoftinoff
Nope. When you close your laptop lid, the ACPI (or whatever O/S you are using) notifies all drivers of the state change before going to sleep. How do they know that the JVM has restarted from an earlier state?
Pontus Gagge
But none of the applications are notified of the sleep state when the lid is closed. Java applications do not contain drivers.. There is no reason that a JVM can't do this - Smalltalk does this all the time, see Squeak, the image is just a hibernated vm state.
jdkoftinoff
+1  A: 

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.

SCdF