This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: locks on X86
- To: "Boehm, Hans" <hans_boehm at hp dot com>
- Subject: Re: locks on X86
- From: Bryce McKinlay <bryce at albatross dot co dot nz>
- Date: Tue, 13 Mar 2001 14:51:43 +1300
- CC: "'green at redhat dot com'" <green at redhat dot com>, Jeff Sturm <jsturm at one-point dot com>, java at gcc dot gnu dot org, drepper at redhat dot com
- References: <140D21516EC2D3119EE7009027876644049B5CA6@hplex1.hpl.hp.com>
"Boehm, Hans" wrote:
> I'm assuming that on X86 we'll usually use hash synchronization. I believe
> there will be exactly two time critical instances of cmpxchg in libgcj
But don't we (eventually) want to have the compiler be able to inline the
"lightweight" part of the synchronization mechanism? I was imagining that the
compiler will generate an inline compare-and-exchange which only calls out to
an external function if contention is detected. The external function would do
the spinning and deal with heavyweight (contended) locks.
Of course, the disadvantage here, as Anthony suggests, is that we'd have to
multilib if we wanted faster synchronization on uniprocessors. Obviously if we
don't do any inlining then its much easier because we just generate two
implementation of the lock function, and figure out at runtime which one to
use. Would the benifit of being able to drop the lock prefix outweigh the
benefit of inlining?
regards
[ bryce ]