Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (hermes.apache.org: domain of davanum@gmail.com designates
 64.233.170.204 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=gdaDh1R7uiuAhqNemE8aJvRxmHh6CVZOvVNC/mXoJFq8/9/arJpJj/oNq+N4uKJIINpz3PQCeNVG03JYxQb/IzMRFn/VmScpXhjtWqhL3gf+AwcRunt/QQ2t5y8XMuF6nEo8/IbmACSVV5/fEOTR7VX/m4ZsMSK6P2nH1QjL/kM=
Message-ID: <19e0530f0505171549367f789b@mail.gmail.com>
Date: Tue, 17 May 2005 18:49:19 -0400
From: Davanum Srinivas <davanum@gmail.com>
Reply-To: dims@apache.org
To: harmony-dev@incubator.apache.org
Subject: Re: Introduction, and a question
In-Reply-To: <E0467379DD4FA84BAF6E42D3161A9A08B14D29@inhyms21.ca.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <E0467379DD4FA84BAF6E42D3161A9A08B14D29@inhyms21.ca.com>

nice to see u here sundar :)

On 5/17/05, Subramanian, Sundar <Sundar.Subramanian@ca.com> wrote:
> My original intention of having a snapshot was not so much as to have a q=
uick restart but to be able to migrate apps a la distributed JVM efforts (h=
ttp://djvm.anu.edu.au/) as Steve has mentioned in this thread earlier.
>=20
> 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 part=
ial solution. But taking care of the environmental parameters like open JDB=
C connections etc would also have to be implemented if any movement in this=
 direction is to be expected.
>=20
> Regards
> ~sundar
>=20
> -----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
>=20
> >
> > El lun, 16-05-2005 a las 16:08 +0530, Subramanian, Sundar escribi=F3:
> > (...)
> > > 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.
> >
>=20
> This looks like it would be related to the stuff Sun has done with class =
data sharing in the 1.5 JVMs:
>=20
> "When the JRE is installed on 32-bit platforms using the Sun provided ins=
taller, 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 Microsof=
t 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 classe=
s and allowing much of the JVM's metadata for these classes to be shared am=
ong multiple JVM processes." [1]
>=20
> 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.
>=20
> Nick
>=20
> [1] http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html
>=20
>=20
> IMPORTANT: This e-mail, including any attachments, may contain private or=
 confidential information. If you think you may not be the intended recipie=
nt, 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 inten=
ded recipient, you must not reproduce any part of this e-mail or disclose i=
ts contents to any other party.
> This email represents the views of the individual sender, which do not ne=
cessarily reflect those of education.au limited except where the sender exp=
ressly states otherwise.
> It is your responsibility to scan this email and any files transmitted wi=
th it for viruses or any other defects.
> education.au limited will not be liable for any loss, damage or consequen=
ce caused directly or indirectly by this email.
>=20
>=20
>=20


--=20
Davanum Srinivas - http://webservices.apache.org/~dims/