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
