harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Introduction, and a question
Date Tue, 17 May 2005 14:58:12 GMT
Santiago Gala wrote:
> 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.


Mime
View raw message