Darwin/MacOSX Support - May 20, 2003 ==================================== Important Usage Notes ===================== GC_init() MUST be called before calling any other GC functions. This is necessary to properly register segments in dynamic libraries. This call is required even if you code does not use dynamic libraries as the dyld code handles registering all data segments. The incremental collector is still a bit flaky on darwin. It seems to work reliably with workarounds for a few possible bugs in place however these workaround may not work correctly in all cases. There may also be additional problems that I have not found. Implementation Information ========================== Darwin/MacOSX support is nearly complete. Thread support is reliable on Darwin 6.x (MacOSX 10.2) and there have been reports of success on older Darwin versions (MacOSX 10.1). Shared library support had also been added and the gc can be run from a shared library. There is currently only support for Darwin/PPC although adding x86 support should be trivial. Thread support is implemented in terms of mach thread_suspend and thread_resume calls. These provide a very clean interface to thread suspension. This implementation doesn't rely on pthread_kill so the code works on Darwin < 6.0 (MacOSX 10.1). All the code to stop the world is located in darwin_stop_world.c. The original incremental collector support unfortunatelly no longer works on recent Darwin versions. It also relied on some undocumented kernel structures. Mach, however, does have a very clean interface to exception handing. The current implementation uses Mach's exception handling. Much thanks goes to Andrew Stone, Dietmar Planitzer, Andrew Begel, Jeff Sturm, and Jesse Rosenstock for all their work on the Darwin/OS X port. -Brian Alliet brian@brianweb.net Older Information (Most of this no longer applies to the current code) ====================================================================== While the GC should work on MacOS X Server, MacOS X and Darwin, I only tested it on MacOS X Server. I've added a PPC assembly version of GC_push_regs(), thus the setjmp() hack is no longer necessary. Incremental collection is supported via mprotect/signal. The current solution isn't really optimal because the signal handler must decode the faulting PPC machine instruction in order to find the correct heap address. Further, it must poke around in the register state which the kernel saved away in some obscure register state structure before it calls the signal handler - needless to say the layout of this structure is no where documented. Threads and dynamic libraries are not yet supported (adding dynamic library support via the low-level dyld API shouldn't be that hard). The original MacOS X port was brought to you by Andrew Stone. June, 1 2000 Dietmar Planitzer dave.pl@ping.at Note from Andrew Begel: One more fix to enable gc.a to link successfully into a shared library for MacOS X. You have to add -fno-common to the CFLAGS in the Makefile. MacOSX disallows common symbols in anything that eventually finds its way into a shared library. (I don't completely understand why, but -fno-common seems to work and doesn't mess up the garbage collector's functionality). Feb 26, 2003 Jeff Sturm and Jesse Rosenstock provided a patch that adds thread support. GC_MACOSX_THREADS should be defined in the build and in clients. Real dynamic library support is still missing, i.e. dynamic library data segments are still not scanned. Code that stores pointers to the garbage collected heap in statically allocated variables should not reside in a dynamic library. This still doesn't appear to be 100% reliable. Mar 10, 2003 Brian Alliet contributed dynamic library support for MacOSX. It could also use more testing.