harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David P Grove <gro...@us.ibm.com>
Subject Re: delegating VM function (was: Re: Eclipse part 2)
Date Tue, 26 Jul 2005 20:32:59 GMT
I was reminded off-list that Jikes RVM's use of GNU classpath's VM/library 
interface was more complex than I'd described in my previous note.  The 
Foo/VMFoo works quite nicely for us in many cases, especially when the 
VMFoo class is a holder for VM-specific static methods (eg, VMRuntime, 
VMSystem, VMString, VMDouble).  Jikes RVM don't use it for truly core 
classes like java.lang.ref.*, java.lang.Class, java.lang.Thread, or 
java.lang.Throwable where we want more control over the instance fields of 
the object and/or don't want to incur an extra indirect to get to 
VM-specific instance data.

Also, GNU classpath doesn't (can't) provide a working reference 
implementation for every method of every VMFoo class (or even a few other 
classes like java.lang.reflect.Method and its ilk), so the distinction 
between its interface and the kernel approach Graeme and Tim described is 
more a matter of degree and naming convention as opposed to a sharp 
difference.  GNU classpath has a smaller set of mandatory kernel classes 
that the VM must provide, and also has a "policy" that native methods get 
segregated into separate classes (which is good for whacky VM's like Jikes 
RVM that aren't implemented in C, and isn't supposed to hurt  C-based VM's 
assuming reasonable levels of inlining). 


View raw message