harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Subramanian, Sundar" <Sundar.Subraman...@ca.com>
Subject RE: Introduction, and a question
Date Wed, 18 May 2005 08:05:45 GMT
What you are suggesting would be a definite must-have if we want to try for a distributable

I will read up on the links supplied and get back on this.

-----Original Message-----
From: Brad Cox [mailto:bradjcox@gmail.com] 
Sent: Wednesday, May 18, 2005 4:40 AM
To: harmony-dev@incubator.apache.org
Subject: Re: Introduction, and a question

My ambitions were far more modest, cutting down on startup overhead in 
apps coded like this

static Foo aFoo = new Foo();
public void main(String args[])
    // on with the show

But JVM/instance persistence would certainly be nice (if hard to provide 

Subramanian, Sundar 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.
>-----Original Message-----
>From: Nick Lothian [mailto:nlothian@educationau.edu.au] 
>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.
>>>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.
>[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. 

View raw message