[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Classpath build process and VM-specific issues

From: Robert Lougher
Subject: Re: Classpath build process and VM-specific issues
Date: Mon, 29 Mar 2004 13:26:07 +0000

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

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

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.


Express yourself with cool emoticons - download MSN Messenger today!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]