harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Blackburn <Steve.Blackb...@anu.edu.au>
Subject Re: Against using Java to implement Java (Was: Java)
Date Sat, 14 May 2005 04:44:50 GMT

> I'd be interested in hearing more from Steve on how well that works 
> within JikesRVM. From reading some papers on the web, it seems that 
> the MMTk has been ported to other, non-Java runtimes as well, and I 
> guess that this binding-vm-components-via-java-interfaces problem has 
> been efficiently solved by other bright people already outside the 
> pure-java-runtime space. 

Actually Robin Garner is the expert, as he wrote his honors thesis on 
the subject.  http://eprints.anu.edu.au/archive/00002397/  (MMTk was 
previously known as JMTk---we dropped the 'J' to reflect our goals of 
language neutrality).

The short answer is that it is easy enough to compile up the bulk of 
MMTk into a library using gcj.  However, for fine-grained interactions 
(not an issue with a compiler, but a real issue with write barriers and 
allocation sequences), one really does not want to go through a C->Java 
transition each time.  What one really wants is for the barrier and 
allocation fast paths to be compiled into the user application code.  In 
a Java-in-Java system, this happens naturally and automatically (since 
both the user app and the barrier are in Java and the compiler can 
inline the barrier code trivially).  Otherwise it is a little harder to 
make this perform well.  Exactly how one would approach it would depend 
on how the compiler dealt with allocation sequences and barriers.

As to the broader issue of componentization etc, here's a very brief 
overview.   I will try to get a better technical write up available to 
everyone soon...

The model is that MMTk has a reasonably well defined public interface, 
which we think of in loose software engineering terms as its "features" 
and "requirements", where the features are a much larger set than the 
requirements.  Likewise the host VM has features and requirements with 
regards to memory management.  We then build adaptors in each direction, 
satisfying the MM requirments with that VM's features, and satisfying 
the VM requirements with that MM's features.  That glue code is 
critical, but actually fairly modest.  This is how Jikes RVM and MMTk 
interact today, adn also how Rotor and (soon) jnode glue into MMTk too.  
The glue code can be written under whatever license you like.  You then 
just link your VM against MMTk.  The key to all of this (and this really 
is the key!) is that the core of MMTk is strictly VM neutral and has no 
VM-specific code in it whatsoever.  This VM neutral core is clearly 
separated, with all VM-specific code falling under a separate 
sub-package (org.mmtk.vm) with well defined dummy classes.  This means 
MMTk is never "ported", rather one just writes a suitable adaptor.  The 
above only works once one has got the abstractions right.

I hope this helps.


View raw message