On 29 Jun 2006, at 11:04, Jeroen Frijters wrote: > Andrew John Hughes wrote: >> Based on your comments, it seems you agree with my original intuition >> of making this a native VM call (by default) in the majority of >> cases, but efficiency would seem to be fairly VM specific. > > Sure, but Thread.getState() is unlikely to be used very often and > should > definitely not be performance critical, so it makes sense to have > it do > some more work, instead of doing the work upfront. > I was thinking more of the VM tracking the state e.g. when join() is called, it has to transition the state to TIMED_WAITING or WAITING (depending on whether a timing was specified), but it should definitely be better for the VM just to handle all of these in a central place. I don't want I was thinking by changing it now, to be honest. >> I suppose I was aiming on lightening the load on the VM interface, as >> I seem to be throwing tons down there lately. I'd be interested in >> comments from other VM coders as to what they feel is best. > > Providing a correct (but, for example, inefficient) default > implementation is a great idea for the VM interface, but IMHO we > should > not be providing partial implementations. A compile error or exception > is way better than subtly incorrect behavior. > Agreed. >> I'll revert to something similar this evening, but the real >> test will be when I add some of this to gcj. > > Thanks. I've already implemented the interface in IKVM, so my feedback > is based on real experience ;-) > You seem to do these things very quickly on IKVM; good to have someone testing this mess I'm making... :) > Regards, > Jeroen > > Cheers, -- Andrew :) Postgraduate Student Verification and Testing Group Department of Computer Science University of Sheffield
