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
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
