Re: VMThrowable.java

[Mark Wielaard]

Hi,

On Thu, 2003-02-20 at 22:20, Archie Cobbs wrote:
> Ideally, a JVM should "just work" with the default classpath sources, and
> this seems to be an explicit goal of classpath. In particular, one should
> not have to modify the Java source files for each JVM (i.e., the files in
> "vm/reference" should work for most JVM's).

Everything *outside* vm/reference should work out of the box for every
VM. At least if we can implement the native stuff in JNI and the VM
supports JNI.

The classes in vm/reference are mostly VM dependent and can not always
be implemented in a way that will (efficiently) work for every VM. So in
principle all a VM implementor has to do is look at the classes inside
vm/reference and adapt them to their own VM. (In theory that is...)

In practise a lot of code in vm/reference is still VM independent so
should/could be moved outside vm/reference into the actual package with
only small VM state/helper classes left inside vm/reference. The trick
is to know which parts can actually be implemented (efficiently) VM
indepeendent and what VM dependent interface to keep in vm/reference.
(Clearly this is a work in progress and a lot of how it works now comes
from when Japhar was the only VM that used GNU Classpath - that was
before there was any 1.2 class support. And from before I joined the
project.)

> Howver, the java.lang.VMThrowable class doesn't seem to follow this rule,
> because fillInStackTrace() and getStackTrace() are not native methods.
> I.e., most JVM's would want to actually implement these methods, and that
> means not only implementing native methods but modifying VMThrowable.java
> to make the methods native in the first place. This seems to me like an
> oversight.

I didn't know how to implement VMThrowable in a VM independent manner so
I just implemented it in a way that always works but doesn't do anything
usefull. There are actual implementations of this class for libgcj and
Kissme, but I don't believe that they can be made general enough to work
out of the box on every VM.

> As a side note, why does VMThrowable.getStackTrace() take a Throwable
> parameter? It seems unnecessary.

The libgcj implementation uses that parameter to strip any throwable
method calls from the actual StackTraceElements returned. It might not
be necessary in every implementation though. I believe the Kissme
implementation ignores it.

> Apologies in advance if I'm confused :-)

No, please ask. This is an area that is not documented enough and VM
implementers must really give us feedback on how they actually use this
stuff.

See for another examples of how I think the core classes and their
vm/reference counterparts should evolve the suggestion for splitting
Thread into a VM independent Thread and a VM dependent VMThread class:
http://mail.gnu.org/archive/html/classpath/2002-10/msg00009.html
(I have not found the time/opportunity to actually implement this yet.)

Cheers,

Mark