Re: Classpath build process and VM-specific issues

[Archie Cobbs]

Robert Lougher wrote:
> > > - 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.

Hmm.. sounds like JamVM does the same thing as I described pretty much.
Why then "unhappy" ? I must be missing something.

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com