[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: VMThrowable.java
From: |
Tom Tromey |
Subject: |
Re: VMThrowable.java |
Date: |
20 Feb 2003 18:20:34 -0700 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
>>>>> "Mark" == Mark Wielaard <address@hidden> writes:
Mark> No, please ask. This is an area that is not documented enough and VM
Mark> implementers must really give us feedback on how they actually use this
Mark> stuff.
I haven't looked at the reference VM code too much. The javadoc there
looks pretty reasonable to me. Maybe the next step would be a
package.html file to explain how it all fits together...
Mark> See for another examples of how I think the core classes and their
Mark> vm/reference counterparts should evolve the suggestion for splitting
Mark> Thread into a VM independent Thread and a VM dependent VMThread class:
Mark> http://mail.gnu.org/archive/html/classpath/2002-10/msg00009.html
Mark> (I have not found the time/opportunity to actually implement this yet.)
In general I think this separation makes a lot of sense. It makes it
easier for us to provide a VM authors with the information they need
to port Classpath, and it makes it easier for us to say what has to
change in VM support code from release to release -- we can just diff
the VM reference code.
The only problem I have with this approach is when a particular method
is performance-sensitive; then the extra call is wasteful (as opposed
to a native method directly in the standard class). For libgcj we can
just maintain a small divergence in these cases. Ideally I prefer to
avoid these divergences. I'm not sure how much this consideration
applies to other VMs.
Tom