nice to see u here sundar :) On 5/17/05, Subramanian, Sundar <[EMAIL PROTECTED]> wrote: > My original intention of having a snapshot was not so much as to have a quick > restart but to be able to migrate apps a la distributed JVM efforts > (http://djvm.anu.edu.au/) as Steve has mentioned in this thread earlier. > > As you say I guess persistence along with machine specific JIT code might be > a hard problem to solve. Sun's efforts in this direction is a good partial > solution. But taking care of the environmental parameters like open JDBC > connections etc would also have to be implemented if any movement in this > direction is to be expected. > > Regards > ~sundar > > -----Original Message----- > From: Nick Lothian [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 17, 2005 10:36 AM > To: harmony-dev@incubator.apache.org > Subject: RE: Introduction, and a question > > > > > 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. > > > > This looks like it would be related to the stuff Sun has done with class data > sharing in the 1.5 JVMs: > > "When the JRE is installed on 32-bit platforms using the Sun provided > installer, the installer loads a set of classes from the system jar file into > a private internal representation, and dumps that representation to a file, > called a "shared archive". Class data sharing is not supported in Microsoft > Windows 95/98/ME. If the Sun JRE installer is not being used, this can be > done manually, as explained below. During subsequent JVM invocations, the > shared archive is memory-mapped in, saving the cost of loading those classes > and allowing much of the JVM's metadata for these classes to be shared among > multiple JVM processes." [1] > > This isn't quite the same as saving JIT'ed code, but it sounds like it is > saving the pre-parsed and verified class files. > > Nick > > [1] http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html > > > IMPORTANT: This e-mail, including any attachments, may contain private or > confidential information. If you think you may not be the intended recipient, > or if you have received this e-mail in error, please contact the sender > immediately and delete all copies of this e-mail. If you are not the intended > recipient, you must not reproduce any part of this e-mail or disclose its > contents to any other party. > This email represents the views of the individual sender, which do not > necessarily reflect those of education.au limited except where the sender > expressly states otherwise. > It is your responsibility to scan this email and any files transmitted with > it for viruses or any other defects. > education.au limited will not be liable for any loss, damage or consequence > caused directly or indirectly by this email. > > >
-- Davanum Srinivas - http://webservices.apache.org/~dims/
