Re: Classpath build process and VM-specific issues

[Mark Wielaard]

Hi,

On Sat, 2004-03-27 at 00:56, Steven Augart wrote:
> Etienne Gagnon wrote:
> > [Some VMs, like JikesRVM tend to completely replace some base classes
> > by their own; SableVM does not].
> 
> Jikes RVM's rvmrt.jar overrides exactly eleven non-VM* classes from a 
> default Classpath installation's glibj.zip:
> 
>       java.lang.Class
>       java.lang.Object
>       java.lang.Thread
>       java.lang.Throwable
>       java.lang.ref.PhantomReference
>       java.lang.ref.Reference
>       java.lang.ref.SoftReference
>       java.lang.ref.WeakReference
>       java.lang.reflect.Constructor
>       java.lang.reflect.Field
>       java.lang.reflect.Method

I like to know what prevents JikesRVM currently from sharing these
classes. I hope to go to a model like SableVM apparently has were none
of the core classes need to be overridden (even though some VMs might
still opt to do it anyway).

I had hoped that the VM interface for Class, Object, Thread and
Throwable was usable for most VMs. What isn't in your case?

I admit not to have looked into or thought about java.lang.ref support
yet. How many VMs based on GNU Classpath properly implement those?

java.lang.reflect should be refactored. I don't think there is a real
reason for a VM to have specific versions of those (given properly
designed VM interfaces of course). But I don't have had time yet to work
on it. Hopefully some of the work done by the SableVM hackers will help
here.

Cheers,

Mark

signature.asc
Description: This is a digitally signed message part