classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: VMInterface addition: Make native library names part ofVMInterface


From: David P Grove
Subject: Re: VMInterface addition: Make native library names part ofVMInterface
Date: Thu, 6 Nov 2003 08:34:06 -0500


Jikes RVM uses a mostly unmodifed classpath.  We don't require users to patch any classpath sources, but there are currently 12 non-VM classes for which we provide our own implementation.
        java.lang.ref: PhantomReference, Reference, SoftReference, WeakReference
        java.lang: Class, Object, Runtime, Thread, Throwable
        java.lang.reflect: Constructor, Field, Method

Some of this is historical (we had the classes already and haven't had the bandwidth to try to integrate our versions with classpath).  In the case of java.lang.ref.* we really needed to do something different than what classpath provided, and I don't see that changing (and the classes are tiny anyways).  There may be hope for merging some of the java.lang and java.lang.reflect classes eventually.

Jikes RVM cares a lot about efficiency, but we have different constraints than gcj.  It's very easy for us to inline across classes without breaking any semantics.  The VM itself is also written in Java (with some extensions to allow the VM to do type unsafe things like implement a GC), so for us efficiency usually means avoiding native methods and staying in Java+VM_Magic (this is what motivated the VMFloat/VMDouble changes I contributed to classpath a while back...Jikes RVM can do these operations much more efficiently by staying in Java instead of calling a native method).  But, an extra level of final methods is harmless for us, we inline it all away.

--dave
reply via email to

[Prev in Thread] Current Thread [Next in Thread]