GC and Linux/SPARC?

Boehm, Hans hboehm@exch.hpl.hp.com
Thu Nov 11 14:25:00 GMT 1999


Jeff Sturm wrote:
> I don't understand why the GC code couldn't fall back on
> pthread_mutex_lock when no test_and_set is available.  It is a little
> slower but should be safe since pthread_mutex_lock doesn't allocate
> memory.

It could, it should, and it's easy to do so.  I just put a first attempt
into my version.  (The HPUX support in the latest released version also does
something
very similar.)

It sounds like the resulting performance is acceptable for Linux threads.
The original
reason for putting the spin-lock code there was that Pthread implementations
that try
to be serious about fairness often end up with intolerable performance on a
uniprocessor
for something like an allocation lock.  In particular, if unlocking a mutex
with waiters
causes mutex ownership to be passed to the next mutex without an immediate
context
switch, you quickly end up with one context switch per lock acquisition on a
uniprocessor.
(I'll leave it as an exercise to the reader to see why this happens.)

Hans


More information about the Java mailing list