This is the mail archive of the
mailing list for the Java project.
locks on X86
- To: java at gcc dot gnu dot org, "'drepper at redhat dot com'" <drepper at redhat dot com>
- Subject: locks on X86
- From: "Boehm, Hans" <hans_boehm at hp dot com>
- Date: Mon, 12 Mar 2001 12:38:33 -0800
Chris Dodd pointed out on the GC mailing list that on recent Intel X86
- cmpxchg without a lock prefix is much faster (roughly 3x or close to 15
cycles by my measurements) than either xchg (implied lock prefix) or lock;
- cmpxchg without the lock prefix is atomic on uniprocessors, i.e. it's not
As far as I can tell, none of the GNU libraries currently take advantage of
this fact. Should they?
This argues, for example, that I could get noticable additional speedup from
Java hash synchronization on X86 by overwriting a few strategic "lock"
prefixes with "nop"s when I notice that there's only one processor
configured. That may not be the cleanest way to implement this, but you get
the idea. My best guess is that this would reduce the times for the UCSD
synchronized method call benchmark by another 15-20% on uniprocessors, and
is likely to contribute 5% on some real applications.
Should linuxthreads also do something along these lines?