Re: Classpath build process and VM-specific issues

[Archie Cobbs]

Mark Wielaard wrote:
> environment. By marking the VMWhatever classes as package local, final
> and naming them specially I had kind of hoped that Compilers/VMs would
> easily inline/optimize away extra calls and/or inline VM-specific fields
> in the non-VM specific instance. Maybe something for the future, but
> maybe it just won't happen.

Right now JC doesn't inline, but hopefully soon it will. So then
my reason for eliminating extra method calls will go away. Again,
just goes to show that priorities are different for different VMs
and even different versions of the same VM.

> > - 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 am probably screwing up on the subtle issues :-) I did things this way
to get Thread.interrupt() working and didn't think too hard about it.
I'd be interested in hearing more about the subtle issues. FWIW here it is:

http://cvs.sourceforge.net/viewcvs.py/*checkout*/jcvm/jcvm/java/java/lang/Thread.java?rev=1.2

-Archie

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