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)
Mime-Version: 1.0 (Apple Message framework v728)
In-Reply-To: <BAY103-F27186DCCF1B133CCB0C70A9110@phx.gbl>
References: <BAY103-F27186DCCF1B133CCB0C70A9110@phx.gbl>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <5AB4C453-4FEA-445E-91B6-B0FE3ACF0212@mac.com>
Content-Transfer-Encoding: 7bit
From: tumnus@mac.com
Subject: Re: Against using Java to implement Java (Was: Java)
Date: Thu, 12 May 2005 17:30:12 +0100
To: harmony-dev@incubator.apache.org


On 12 May 2005, at 12:17, theUser BL wrote:

> I hope you use C to write the VM for Harmony.
>

Forgive me if I am repeating what others have already said - I'm a  
bit late to this.

Bootstrapping the whole thing in Java is a very clever idea, but what  
about the management of the heap (GC etc)? Presumably that would have  
to be done in some layered system, with a very simplistic GC in the  
bootstrap VM, with layers of extra logic on top of it? Or am I  
missing something?

If so, what sort of performance hit would this have? I agree that in  
many ways it is a Good Thing, but so was Sun's handle redirection  
stuff (where an object reference referred to a table, that referred  
to the object) but Microsoft's Bad Way of simply linking to the  
object ran much quicker. In fact, didn't Sun eventually switch to  
that way of working? I think there was something about it in Simon  
Ritter's talk on GC at last year's London Java Tech days.

I know very little about all this (so please beat me only with a very  
small stick and in a loving manner) but would it be possible to start  
with an existing(?) JVM written in C/C++ and then start to migrate it  
part by part into Java? Taking the baby steps approach, couldn't we  
work out exactly where the log-jams are likely to be? And then get as  
much as we can in Java, so long as it doesn't have a significant  
impact on performance?

Would taking the C/C++ --> Java approach mean that we could base our  
discussions upon the evidence of the code, and less upon subjective  
belief? More ground up and less BUFD?

DG