gc-7.2/doc/README.solaris2

   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 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 Note:
  21 Before you run "make check", you need to set your LD_LIBRARY_PATH correctly
  22 (eg., to "/usr/local/lib") so that tests can find the shared library
  23 libgcc_s.so.1.  Alternatively, you can configure with --disable-shared.
  24
  25 SOLARIS THREADS:
  26
  27 Threads support is enabled by configure "--enable-threads=posix" option.
  28 (In case of GCC compiler, multi-threading support is on by default.)
  29 This causes the collector to be compiled with -D GC_THREADS (or
  30 -D GC_SOLARIS_THREADS) ensuring thread safety.
  31 This assumes use of the pthread_ interface.  Old style Solaris threads
  32 are no longer supported.
  33 Thread-local allocation is now on by default.  Parallel marking is on by
  34 default starting from GC v7.3 but it could be enabled or disabled manually
  35 by the corresponding "--enable/disable-parallel-mark" options.
  36
  37 It is also essential that gc.h be included in files that call pthread_create,
  38 pthread_join, pthread_detach, or dlopen.  gc.h macro defines these to also do
  39 GC bookkeeping, etc.  gc.h must be included with one or both of these macros
  40 defined, otherwise these replacements are not visible.  A collector built in
  41 this way way only be used by programs that are linked with the threads library.
  42
  43 Since 5.0 alpha5, dlopen disables collection temporarily,
  44 unless USE_PROC_FOR_LIBRARIES is defined.  In some unlikely cases, this
  45 can result in unpleasant heap growth.  But it seems better than the
  46 race/deadlock issues we had before.
  47
  48 If threads are used on an X86 processor with malloc redirected to
  49 GC_malloc, it is necessary to call GC_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  SEGV faults.  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 I encountered "symbol <unknown>: offet .... is non-aligned" errors.  These
  64 appear to be traceable to the use of the GNU assembler with the Sun linker.
  65 The former appears to generate a relocation not understood by the latter.
  66 The fix appears to be to use a consistent tool chain.  (As a non-Solaris-expert
  67 my solution involved hacking the libtool script, but I'm sure you can
  68 do something less ugly.)
  69
  70 Hans-J. Boehm
  71 (The above contains my personal opinions, which are probably not shared
  72 by anyone else.)