Interrupted IO and AWT
Wed Mar 22 17:30:00 GMT 2000
I haven't done much performance testing of GC_lock(). It does seem to be
appreciably faster than the pthread_mutex locking, apparently because there
is somewhat less work being done, there is one less level of procedure call,
it's less likely to enter the kernel on an SMP, and it doesn't need to do a
compare_and_swap on exit.
GC_lock isn't quite the strategy I had in mind, since it does something more
complicated than exponential back-off when it's spinning. It tries to be
adaptive, but doesn't really back off between successive test_and_set
attempts while it's still spinning. I have no idea how this compares to the
simpler straight exponential back-off strategy.
I agree that the current value of SLEEP_THRESHOLD is problematic on an SMP.
The problem with making it much larger is that sched_yield may be repatedly
yielding to another thread also waiting on the lock. (This can definitely
happen with strict priorities. Hopefully it's unlikely with normal
timesharing priorities.) This may still be a better choice. It would be
nice to be able to sleep for shorter intervals than 500 context switches.
From: Jeff Sturm [ mailto:email@example.com ]
Sent: Tuesday, March 21, 2000 8:54 PM
To: Boehm, Hans
Cc: 'Tom Tromey'; Jeff Sturm; Bryce McKinlay;
Subject: RE: Interrupted IO and AWT
On Tue, 21 Mar 2000, Boehm, Hans wrote:
> It seems to me that a spin lock with exponential back-off (and sleeps for
> longer wait times) doesn't behave that badly, even in this case. There'll
> be some unneeded wakeups on the part of the waiting thread near the
> beginning, and it may sleep for up to about twice as long as it should
> (assuming the base of the exponential is 2). Clearly this is suboptimal
> this case. But are there cases in which it's a serious problem?
I like that idea, it think it would be worthwhile experimenting with it.
Isn't that essentially what you've already done in your GC anyway (in
There's a comment in GC_lock that the minimum useable sleep time
for Linux is 2ms. On one system I measured sched_yield() to consume about
4us on a context switch, 1us when no context switch takes place. It could
do perhaps 1000 iterations of test-and-set/yield in that same interval.
You wouldn't want to sleep too early, or most of that 2ms could be
unnecessarily consumed. The current SLEEP_THRESHOLD of 12 in GC_lock
seems low to me.
I'd question if suspend/resume could be any more effective over such a
duration (~1ms). I don't think so, since any other tasks waiting to run
would be given a chance by yielding anyway.
More information about the Java