[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  
> 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



More information about the Classpath-patches mailing list