[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Classpath build process and VM-specific issues
From: |
Mark Wielaard |
Subject: |
Re: Classpath build process and VM-specific issues |
Date: |
Sun, 28 Mar 2004 19:32:31 +0200 |
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
Re: Classpath build process and VM-specific issues, Patrik Reali, 2004/03/27