Interrupted IO and AWT

[Boehm, Hans]

I'm still planning on looking at this.  But I've been busy with other
things.  (I have a very partial implementation of an alternate locking
scheme, but it's not in any kind of usable shape.  And I'm far less than
100% sure that it will turn out to be the right scheme.)

The rest of this is based on way too few anecdotes, and no real
measurements:

My general impression is that if you don't care much about fairness (and I
suspect we usually don't), spin locks with exponential back-off work quite
well, in that they tend to automatically reduce contention to a reasonable
level.  (It does seem to have the disadvantage that with lots of contention,
you sometimes see individual threads going to very long backoffs.  The net
result is that one or two threads keep the lock for long periods, thus
reducing the need to move the cache line back and forth.  This is probably
the right thing for throughput, but not fairness.)  I tend to implement
short backoff intervals as spins, and longer ones using some sort of sleep
primitive.

For some strange reason, that's a scheme that's rarely discussed in the
literature.  Does anyone have some real measurements that include something
like this scheme?

I'm still looking at a scheme that maintains a global, non-resizable hash
table of locks, with no per-object space for locks.  (Collisions do force
memory allocation.)  My impression is that shrinking objects is very
worthwhile, since it increases the effectiveness of the cache, and decreases
memory bandwidth requirements.  Also I suspect that many Java locks are very
short-lived.  Thus it's important to avoid memory allocation when an object
is first locked (statistics anyone?).  Again this probably favors throughput
over predictability, fairness, etc.  But fairness doesn't help much if the
throughput goes to zero.

Hans
 
-----Original Message-----
From: Jeff Sturm [ mailto:jsturm@sigma6.com ]
Sent: Tuesday, March 21, 2000 8:10 AM
To: Tom Tromey
Cc: Bryce McKinlay; java-discuss@sourceware.cygnus.com
Subject: Re: Interrupted IO and AWT


Tom Tromey wrote:
> Sometimes I wonder if we should have two locking implementations, one
> as fast as possible and one that is perhaps slower but SMP friendly.

I have wondered this too... it seems like improvement ought to be done
in LinuxThreads, not libgcj, though libgcj is a convenient "proving
grounds" for any sort of experimentation.

Re: SMP, the hardware architectures themselves have limits.  I
demonstrated a while ago
( http://sourceware.cygnus.com/ml/java-discuss/1999-q4/msg00064.html )
that SMP synchronization can be brutally slow due to the CPU cache
ping-pong phenomenon.  The easy way to improve your SMP performance is
to downgrade to a uniprocessor... :|  Good multithreaded SMP performance
can be very difficult.

Some architectures can be tweaked for single-processor use.  The Alpha
CPU uses a load-locked/conditional-store strategy for atomic updates,
followed by a memory barrier to synchronize the cache with main memory. 
It is reasonable to leave off the memory barrier on a uniprocessor,
yielding significantly higher throughput.

The x86 architecture relies on atomic swap however, and doesn't seem to
have a similar optimization.

A better question may be: can libgcj benefit from specialized
(architecture-specific) locks?  I'm certain it can, as I re-read
Godmar's post on thin locks:

http://sourceware.cygnus.com/ml/java-discuss/1999-q4/msg00499.html

-- 
Jeff Sturm
jsturm@sigma6.com