On Sun, 2004-03-28 at 23:53, Archie Cobbs wrote: > Mark Wielaard wrote: > > I had hoped that the VM interface for Class, Object, Thread and > > Throwable was usable for most VMs. What isn't in your case? >
JamVM 1.1.1 uses no special versions of these classes (i.e. it uses the VMClass, VMObject and VMThread, VMThrowable, etc., classes). JamVM 1.1.2 also uses VMRuntime, however, it has it's own version of ClassLoader, to fix the findLoadedClass problem.
When the VM interface consisted of static methods on a VM class I was happy to adopt it (even an interpreter can inline the call, but JamVM doesn't do it at the moment). However, I didn't like the move to shadow objects in VMThread and VMClass (VMClass in particular was a lot of trouble to implement). However, it seemed pointless to use some of the interface and not others -- either all or nothing -- I came close to using nothing :)
I am now more or less convinced that in some cases we should even mark it as 'Object'. Again marking it as VMWhatever I had hoped that the compiler/VM would easily be able to handle it specially. See RawData in gcj.
I would prefer the internal VM data field to be of type Object (this is what I use in JamVM). This means it should be the width of a native pointer field, whether the machine is 32 or 64 bit.
- I prefer to avoid the extra method call overhead for important methods like Object.wait() imposed by the VMFoo split. In Classpath every Object.wait() requires calling VMObject.wait(). That makes the code separation cleaner but doesn't make implementation any easier - it's just as easy to implement Object.wait() as a native method as it is to implement VMObject.wait() as a native method.
See above. And the environment is always free to overwrite specific special cases (like Object and Class will almost always be I guess).
But not JamVM. Inlining of final calls is something I intend to look at soon :)
- My Thread class uses private objects to implement sleep() and join() in terms of Object.wait(). The VM notify()'s this object when the thread exits. This means all the complexity of sleeping (and handling Thread.interrupt()) can be put in Object.wait() and not duplicated elsewhere.
Could you post your versions? It might be interesting to see whether we can adopt this approach as default in the vm/reference implementation. VMThread now does have a lot of native methods. But I believe I discussed some of these issues with Jeroen and if I remember correctly there were some subtle issues with just doing everything as wrappers over Object.wait()/notify().
I would be very unhappy about this. Sleep in JamVM is done by waiting on an internal monitor, which is what Object.wait() maps down to (the monitor associated with the Object) and joining threads wait on the vmthread associated with the thread, which is notified on exit. So all code is done in terms of "monitor wait", which handles interrupt, so JamVM doesn't duplicate code either. JamVM uses thin locks which map down to a real monitor in the presence of contention. Join/sleep by definition requires a real monitor, so I side step the redundant monitor lookup.
The current approach allows the VM a lot of freedom. Trying to do too much in Java removes this, and in my opinion forces many VM implementors to abandon the VM interface altogether.
- I folded VMThrowable into Throwable to get rid of VMThrowable. Same reasons as mentioned above.
I can't see the point of this. Exceptions are slow anyway -- what's the cost of an extra indirection to walking the call stack?
- Classpath's reflection implementation is/was incomplete and required modifications to work.
I also modifed these classes to work with JamVM.
Hope these don't sound like complaints - using Classpath has worked out great and I'm very appreciative of it!!
I would second this. I've tried to use the VM interface as much as possible, to stay "true" to the goals of Classpath.
Rob.
_________________________________________________________________
Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath