El lun, 16-05-2005 a las 16:08 +0530, Subramanian, Sundar escribió: (...)
I guess what Brad is asking is for a snapshot of the state of JVM. This would be really useful to migrate stuff from one environment to another preserving the underlying state.
I have mixed feelings about having a "save image" __a la__ Smalltalk, if this is what you are meaning. While delivering an image looks tempting, state gets corrupt in unpredictable ways, and having ways to track changes becomes a nightmare.
The Smalltalk community has worked hard in this (hard) problem, but I'm still not sure if it would make sense in the java world. Java is a system-oriented language, and the ability to save the whole VM state and recover from this saved image would bring additional constraints to the Virtual Machine implementation. For instance, machine specific JIT code should be invalidated upon save, negating a substantial part of the advantages of a saved image (faster startup).
This said, if VM implementors out there find easy ways to meet these constraints w/o burdening runtime or memory requirements, it could be an area for experimenting.
well, there are several things here:
1) saving the JVM memory on disk for faster startup (don't think it makes sense on the server, but on the client it does, think about freezing your eclipse and start it up again as you left it, sure will take less time)
2) persisting "thread continuations" on disk (this *IS* something that makes sense on the server, and practially *the* reason of my interest in Harmony)
these have nothing to do with system portability and image corruption is easily checked with a checksum, in case you want that.
3) the above, but across systems.
I would rule #3 out of scope: bytecode was invented for that, let's not reinvent all the wheels at once.
-- Stefano.
