Re: Thoughts on 'reference classes'

[Mark Wielaard]

Hi,

On Wed, 2003-02-26 at 01:25, Archie Cobbs wrote:
> [ warning, random thoughts below... ]
> 
> I've been working on a new JVM and trying to figure out how
> modify the "vm/reference" classpath classes into something that
> this JVM particular can support.

Fun! Do you have specific needs that non of the current ones fullfill or
do you just like the challenge?

> Something occurred to me while looking at the Java sources under
> vm/reference and reading some messages on this list.
> 
> On the one hand, the 'reference' classes contain many places where
> the particular JVM developer is required or expected to add, subtract,
> or modify the 'reference' Java code to fit that particular JVM.
> >From my point of view this is annoying, because often means I have
> to think hard about how to do something and whether I'm breaking
> some subtle JVM semantics by doing it. But even when it's obvious
> what to do, you still have to create a different version of this
> class which has to be synchronized whenever you update from Classpath.

(Much) better documentation of vm/reference classes would probably help.
We have a VM integration guide, but it hasn't been updated to much (see
http://www.gnu.org/software/classpath/docs/vmintegration.html, source is
in the classpath cvs tree).

But in general the vm/reference classes are meant to be copied
completely and then adapted to your specific VM implementation. We try
to produce default implementations where possible but they are often not
the most optimal for a particular VM.

> For example, VMThrowable.java. While it's clear what the JVM needs
> to do in this case, whatever your JVM, you'll have to do *something*
> with this class if you want to be able to print out exception traces.
> Also, there are lots of other methods that are marked "XXX - Not
> implemented; this requires native help" but are not native methods.
> Why not just make them native so I don't have to modify the file?

The reason to not make this native is that a VM does not have to do
anything really. Exceptions will just work with the default
implementations you just won't have StackTraceElements but that doesn't
seem to be such a big deal (in some environments where there is no
console or user debugging required this might even be the ideal
implementation).

> On the other hand, any proposed changes to the reference classes
> in the interest of making them more 'generally suitable' to the
> widest variety of JVM's, or making them require fewer changes when
> ported to a new JVM, run up against backwards compatibility
> issues, because any such change means some existing JVM somewhere
> will probably have to be adjusted to accomodate.

We are still a very alpha product (0.05) and the VM interface is not
expected to be stable before we reach 1.0. In general when changing a
vm/reference VM interface I try to get it right for gcj and Kissme and
document the change in the NEWS file so when a new release is
distributed VM implementers just go over the NEWS file and change what
is necessary. When the change can be done in java or standard JNI
(Posix) then we can even provide a complete working solution.

> For an example of this, there are lots of places in the reference
> classes that say "this method will be removed in a future version of
> classpath" yet there the method sits.

We might be a bit to soft about this. But mostly these are backward
compatibility methods that just make lives of VM implementers easier if
they want to keep their old infrastructure.

> The tension between these two 'hands' seems to me likely to result
> in a negative effect on the reference code, because you can't easily
> make changes that improve anything. As a result, new JVM implementors
> like me don't get as much value out of the 'reference' code.

Feel free to do suggestions for improvements. Especially when you back
it up with a simple reference implementation (in java or jni) then it
should be easy for other VMs to follow.

> I.e., in my (biased) opinion, ideally the 'reference' classes should
> always reflect the combined wisdom of the Classpath developers'
> about what the best, most correct way is to organize and partition
> the Java code from the native code. If a new way to do something is
> discovered, it should be natural and we should be quick to include
> it in Classpath, even if that changes the Java <-> native API.

I agree. Till we reach 1.0 the VM interface is in flux anyway. And VMs
don't have to follow the Classpath CVS version anyway they can just use
the last release. Brian is doing a good job here making sure that we
have a new release every couple of months (Thansk Brian!).

> What I'd like to suggest is the following (donning flamesuit): the
> goal of the 'reference' code should be explicitly changed so that
> it reflects this 'best guess' at what an 'ideal' set of native
> method classes should look like, and the goal of maintaining support
> for existing JVM's in the 'reference' classes should be dropped.

Sounds good since we currently have just to much cruft from the pre 1.1
days when Japhar was the only supported VM. But only drop old stuff when
we actually have new stuff!

BTW. I don't know if anybody uses Japhar anymore. If so, what version of
Classpath do you use?

It is important though that there is at least one free VM that can at
all times be used with Classpath from CVS. Personally Kissme is my Vm of
choice so I am willing to help John Leuner and Stephen Crawley to keep
that one always up to date with any CVS changes.

I general it is a good idea if anybody that proposes a change for the VM
reference classes makes sure that it makes sense for at least two
somewhat different VMs (say Kissme and gcj, or IKVM.NET and SableVM,
etc).

> In it's place, the existing 'reference' code can be (CVS repository)
> copied into distinct 'vm' subdirectories for each JVM out there
> that currently relies on it. These JVM's can then manage their
> per-JVM classes as they see fit (some may not change anything,
> others may try to migrate toward the 'reference' set).

You mean move old vm/reference classes into the CVS repository of VMs
that actually use them? Agreed, that was how it is supposed to work. But
I think that also new VMs should have this policy.

> Moreover, a second goal for the 'reference' classes should be that it
> is possible for a JVM to be implemented using them without any changes.
> Having methods marked "XXX - Not implemented; this requires native help"
> but not actualy native is neither here nor there.

Don't know if I agree here. Wheter or not a method is marked "native"
does not matter much. Sometimes a method can be implemented "non-native"
by a VM (since it has some other bridging mechanism to the runtime, e.g.
IKVM.NET uses C# library calls, JikesRVM uses "magic" java classes). And
some things just cannot be implemented in a generic fashion, even if one
uses JNI and POSIX like mechanism.

> Hope this makes sense and is not too simplistic a view to take,
> as I'm new to this project. Comments?

Thanks for your enthousiasm, it is contagious :)

Cheers,

Mark