Return to README.solaris2 CVS log

Up to [local] / OpenXM_contrib2 / asir2000 / gc5.3

Annotation of OpenXM_contrib2/asir2000/gc5.3/README.solaris2, Revision 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: Since 5.0 alpha5, dlopen disables collection temporarily,
        !            41: unless USE_PROC_FOR_LIBRARIES is defined.  In some unlikely cases, this
        !            42: can result in unpleasant heap growth.  But it seems better than the
        !            43: race/deadlock issues we had before.
        !            44:
        !            45: If solaris_threads are used on an X86 processor with malloc redirected to
        !            46: GC_malloc, it is necessary to call GC_thr_init explicitly before forking the
        !            47: first thread.  (This avoids a deadlock arising from calling GC_thr_init
        !            48: with the allocation lock held.)
        !            49:
        !            50: It appears that there is a problem in using gc_cpp.h in conjunction with
        !            51: Solaris threads and Sun's C++ runtime.  Apparently the overloaded new operator
        !            52: is invoked by some iostream initialization code before threads are correctly
        !            53: initialized.  As a result, call to thr_self() in garbage collector
        !            54: initialization  segfaults.  Currently the only known workaround is to not
        !            55: invoke the garbage collector from a user defined global operator new, or to
        !            56: have it invoke the garbage-collector's allocators only after main has started.
        !            57: (Note that the latter requires a moderately expensive test in operator
        !            58: delete.)
        !            59:
        !            60: Hans-J. Boehm
        !            61: (The above contains my personal opinions, which are probably not shared
        !            62: by anyone else.)