Return to README.solaris2 CVS log

Up to [local] / OpenXM_contrib2 / asir2000 / gc

Annotation of OpenXM_contrib2/asir2000/gc/README.solaris2, Revision 1.1.1.1

1.1       noro        1: The collector supports both incremental collection and threads under
                      2: Solaris 2.  The incremental collector normally retrieves page dirty information
                      3: through the appropriate /proc calls.  But it can also be configured
                      4: (by defining MPROTECT_VDB instead of PROC_VDB in gcconfig.h) to use mprotect
                      5: and signals.  This may result in shorter pause times, but it is no longer
                      6: safe to issue arbitrary system calls that write to the heap.
                      7:
                      8: Under other UNIX versions,
                      9: the collector normally obtains memory through sbrk.  There is some reason
                     10: to expect that this is not safe if the client program also calls the system
                     11: malloc, or especially realloc.  The sbrk man page strongly suggests this is
                     12: not safe: "Many library routines use malloc() internally, so use brk()
                     13: and sbrk() only when you know  that malloc() definitely will not be used by
                     14: any library routine."  This doesn't make a lot of sense to me, since there
                     15: seems to be no documentation as to which routines can transitively call malloc.
                     16: Nonetheless, under Solaris2, the collector now (since 4.12) allocates
                     17: memory using mmap by default.  (It defines USE_MMAP in gcconfig.h.)
                     18: You may want to reverse this decisions if you use -DREDIRECT_MALLOC=...
                     19:
                     20:
                     21: SOLARIS THREADS:
                     22:
                     23: The collector must be compiled with -DSOLARIS_THREADS to be thread safe.
                     24: It is also essential that gc.h be included in files that call thr_create,
                     25: thr_join, thr_suspend, thr_continue, or dlopen.  Gc.h macro defines
                     26: these to also do GC bookkeeping, etc.  Gc.h must be included with
                     27: SOLARIS_THREADS defined, otherwise these replacements are not visible.
                     28: A collector built in this way way only be used by programs that are
                     29: linked with the threads library.
                     30:
                     31: If you are using the Pthreads interface, also define _SOLARIS_PTHREADS.
                     32:
                     33: In this mode, the collector contains various workarounds for older Solaris
                     34: bugs.  Mostly, these should not be noticeable unless you look at system
                     35: call traces.  However, it cannot protect a guard page at the end of
                     36: a thread stack.  If you know that you will only be running Solaris2.5
                     37: or later, it should be possible to fix this by compiling the collector
                     38: with -DSOLARIS23_MPROTECT_BUG_FIXED.
                     39:
                     40: Jeremy Fitzhardinge points out that there is a problem with the dlopen
                     41: replacement, in that startup code in the library is run while the allocation
                     42: lock is held.  This appears to be difficult to fix, since the collector does
                     43: look at data structures maintained by dlopen, and hence some locking is needed
                     44: around the dlopen call.  Defining USE_PROC_FOR_LIBRARIES will get address
                     45: space layout information from /proc avoiding the dlopen lock.  But this has
                     46: other disadvanatages, e.g. mmapped files may be scanned.
                     47:
                     48: If solaris_threads are used on an X86 processor with malloc redirected to
                     49: GC_malloc, it is necessary to call GC_thr_init explicitly before forking the
                     50: first thread.  (This avoids a deadlock arising from calling GC_thr_init
                     51: with the allocation lock held.)
                     52:
                     53: It appears that there is a problem in using gc_cpp.h in conjunction with
                     54: Solaris threads and Sun's C++ runtime.  Apparently the overloaded new operator
                     55: is invoked by some iostream initialization code before threads are correctly
                     56: initialized.  As a result, call to thr_self() in garbage collector
                     57: initialization  segfaults.  Currently the only known workaround is to not
                     58: invoke the garbage collector from a user defined global operator new, or to
                     59: have it invoke the garbage-collector's allocators only after main has started.
                     60: (Note that the latter requires a moderately expensive test in operator
                     61: delete.)
                     62:
                     63: Hans-J. Boehm
                     64: (The above contains my personal opinions, which are probably not shared
                     65: by anyone else.)