[Gc] GC + dylibs on Darwin/OS X

Boehm, Hans hans_boehm@hp.com
Fri, 7 Mar 2003 09:07:56 -0800

I'm pretty sure some of the PowerPC locking code is broken on multiprocessors.  Look in include/private/gc_locks.h (around line 145 in my version).  Likely problems:

1) GC_test_and_set may need an explicit memory barrier, if that's not included with lwarx/stwcx.  The update to the test and set location must be made visible before subsequent memory accesses.

2) GC_clear currently uses eieio as a memory barrier.  I really like the mnemonic, but I have it on reliable authority that it's the wrong instruction.  (I vaguely remember that the right instruction has a boring name like "sync".)

3) If you are trying to get the parallel marker going, you will have similar issues with GC_compare_and_exchange and GC_memory_barrier.


> -----Original Message-----
> From: Brian Alliet [mailto:brian@brian-web.com]
> Sent: Friday, March 07, 2003 12:47 AM
> To: gc@napali.hpl.hp.com
> Subject: Re: [Gc] GC + dylibs on Darwin/OS X 
> On Thursday, March 6, 2003, at 11:30  PM, Jesse Rosenstock wrote:
> >> There still seem to be some problems with the threading code (from
> >> Jesse Rosenstock's patch). It seems like it randomly hangs 
> every once
> >> and a while. To make things even more interesting, it 
> makes gdb very
> >> upset.
> >
> > Does this happen with gctest, or some other program?  How 
> can I test 
> > it?
> It happens with gctest. It seems more likely to happen when running 
> multiple copies in parallel. If I run "./gctest &" about 10 times one 
> or two almost always hang. In addition, less often, one will blow up 
> with a "Bus error". What kind of system are you running it 
> on? I have a 
> dual g4, if its some strange locking problem it may not occur on a 
> single cpu system. I'll look into it some more this weekend.
> -Brian
> _______________________________________________
> Gc mailing list
> Gc@linux.hpl.hp.com
> https://linux.hpl.hp.com/cgi-bin/mailman/listinfo/gc