This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: criticalsections are very fast / pooling mutexes / how does h ash-sync work?
- From: Adam Megacz <gcj at lists dot megacz dot com>
- To: "'java at gcc dot gnu dot org '" <java at gcc dot gnu dot org>
- Date: 23 Dec 2001 17:35:25 -0800
- Subject: Re: criticalsections are very fast / pooling mutexes / how does h ash-sync work?
- Organization: Myself
- References: <40700B4C02ABD5119F000090278766443BEE66@hplex1.hpl.hp.com>
"Boehm, Hans" <hans_boehm@hp.com> writes:
> I don't understand your concern about moving CriticalSections. The
> collector doesn't move anything. Why would the memory address change?
I'm sure the garbage collector doesn't (there's no way it could know
enough to do this properly), but I suspect that something in natObject
does; if I don't introduce the indirection, it crashes all over the
place. This could be my mistake; I'll double check it.
> I don't think it would be that difficult to port this to win32, and that may
> also be a way around some of these issues, since the fast path no longer
> involves any win32 calls.
Yes, it definately would be.
> You will have to add the appropriate compare-and-swap definition
> (natObject.cc), and supply a few other odds and ends.
Hrm, shouldn't the one that's there for Linux-x86 work? It's just
straight asm, no system calls...
Actually, it seems like it should "just work".. I'm going to give it a
try.
- a