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: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: I hope the JVM implements most using Java itself
Content-Transfer-Encoding: quoted-printable
Date: Wed, 11 May 2005 09:30:21 +0200
Message-ID: <5539E3F44392194B82CA32FF905086D3199BC6@warp.bcn.fact.prv>
Thread-Topic: I hope the JVM implements most using Java itself
Thread-Index: AcVV+tdETa84QcgYSVySQz2nFWuIrwAADjuA
From: "Fig, Ricardo" <R.Fig@fact.es>
To: <harmony-dev@incubator.apache.org>

I agree, I think if JVM can extends current scope possibilities, and =
support to work with RAW memory, will be a very good advantange.

Regards,
Ricardo=20

-----Original Message-----
From: Will Pugh [mailto:willpugh@sourcelabs.com]=20
Sent: mi=E9rcoles, 11 de mayo de 2005 9:27
To: harmony-dev@incubator.apache.org
Subject: Re: I hope the JVM implements most using Java itself

For most applications I would agree. GC is a pretty good way to go, it =
has a number of good properties such as fast allocation, pretty decent =
object grouping in many cases, pretty fast, etc.

However, you still can't work with raw memory, e.g. allocating blocks of =
memory for working with many of the same objects, moving objects around =
in physical memory, physically changing vtables for exisiting Java =
Objects (potentially useful for some optimizations). A JVM has more to =
do than just turn bytecode into native code, it also needs to manage =
memory, changing already JITed machine code, potentially changing =
existing object layouts/vtables.


--Will