Re: Classpath build process and VM-specific issues

[Robert Lougher]

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