Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <4292F2DF.4090401@anu.edu.au>
Date: Tue, 24 May 2005 19:24:47 +1000
From: Steve Blackburn <Steve.Blackburn@anu.edu.au>
Reply-To: Steve.Blackburn@anu.edu.au
Organization: Australian National University
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: Terminology etc
References: <4292C425.50408@anu.edu.au> <4292EA7F.9070507@earthlink.net>
In-Reply-To: <4292EA7F.9070507@earthlink.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dmitry Serebrennikov wrote:

> A quick proposal: perhaps "VM bootstrap" as used below should really 
> be something like "VM initialization," "VM init," or even "VM 
> startup", since the word "bootstrap" is very specific and to me at 
> least, indicates something more akin to the "VM bootloader" + "VM boot 
> image" (as used below).

That sounds fine with me.  It is hard to move outside one's own 
(limited) terminology :-).  We have "boot()" methods on each of the key 
components and a "boot()" method in the vm core which calls these.  
That's the origins of my terminology.  Init seems reasonable and 
disambiguates the role of the bootloader.  Probably the original 
rationale for using the "boot" word is that there is a higher level of 
"bootstrapping" going on here---getting the classloader loaded before 
you have a class loader ;-) etc etc.  But I agree, "init" may be helpful.

> * "OS interface" is perhaps one place where some code can be shared. 
> If C version can benefit from an OS abstraction layer for portability, 
> then it seems like this layer could be shared between the C and the 
> Java implementations.

I agree.  It turns out to be a tiny amount of code though (in the case 
of Jikes RVM, at least).

> * The meat of the VM seems to be in the "spokes" that connect to the 
> "VM core-hub". It seems that this is where it would make the most 
> sense to mix components written in C with those written in Java, to 
> see which one can do a better job. If all spokes were in C, it would 
> make little sense to have the hub be in Java... On the other hand if 
> spokes are all Java, it makes little sense to have the hub be in C.
>
> Steve, if the spokes were in Java but the hub in C, would we then lose 
> all of the aggressive inlining benefits that Java-in-Java solution can 
> provide?

I don't know.  These are really interesting questions and ones I think 
we need to hear lots of informed opinion on.  My experience with mixing 
C & Java inside the VM is limited to the interface to the MM.  The 
inlining issue is key there because of the fine grain at which those 
interactions occur.  Scheduling, compilation and classloading are very 
much coarser grained, so those issues are much less critical there...

Cheers,

--Steve