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.