[cp-patches] FYI: Handle thread state
Andrew John Hughes
a.hughes at dcs.shef.ac.uk
Thu Jun 29 10:16:52 UTC 2006
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
> 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
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
>> 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
> not be providing partial implementations. A compile error or exception
> is way better than subtly incorrect behavior.
>> 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... :)
Verification and Testing Group
Department of Computer Science
University of Sheffield
More information about the Classpath-patches