This is the mail archive of the
java-discuss@sourceware.cygnus.com
mailing list for the Java project.
RE: GC and Linux/SPARC?
- To: "'Jeff Sturm'" <jsturm at sigma6 dot com>, Alexandre Oliva <oliva at lsd dot ic dot unicamp dot br>
- Subject: RE: GC and Linux/SPARC?
- From: "Boehm, Hans" <hboehm at exch dot hpl dot hp dot com>
- Date: Thu, 11 Nov 1999 14:25:35 -0800
- Cc: Bryce McKinlay <bryce at albatross dot co dot nz>, java-discuss at sourceware dot cygnus dot com
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