harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Tromey <tro...@redhat.com>
Subject Re: a harmonious and inclusive community
Date Tue, 26 Jul 2005 17:34:01 GMT
>>>>> "Geir" == Geir Magnusson <geirm@apache.org> writes:

Geir> But on a serious note, would it be possible for someone to give a
Geir> good technical description of the GNU Classpath VM interface so that
Geir> people who aren't aware and for whatever reason can't read it on the
Geir> classpath site due to legal reasons can be brought up to speed?

The basic idea in Classpath is that all VM decisions are delegated to
a set of VM-specific classes.  A reference set of classes are provided
to make it simpler for a VM to implement the necessary glue.

Exactly which things are considered "VM decisions" is decided in an ad
hoc way.

Typically a VM class will appear in the same package as its users and
will use package-private protections so that malicious code can't
circumvent security checks.

To take a simple example, ClassLoader.defineClass() is a wrapper
around VMClassLoader.defineClass().  The latter is a static
VM-specific method.  In the reference implementation it is declared
'native' (we compile Classpath against the reference implementation).


The reason we went this route instead of just requiring each VM to
provide its own implementation of each core class (e.g. ClassLoader)
is that the classes in question are largely shared code with a very
small amount of VM-specific glue.

In fact we have a good case study that this tradeoff is the right one
in libgcj -- libgcj still provides its own versions of some core
classes like String and Object.  We periodically have to merge over
bug fixes and javadoc and the like.  It seems to me that the other
classpath-using VMs have it simpler here, as they just require the
occasional tweak to their VM classes.


Let me know if you want more info.

Tom

Mime
View raw message