[BACK]Return to README.solaris2 CVS log [TXT][DIR] Up to [local] / OpenXM_contrib / gc

Diff for /OpenXM_contrib/gc/Attic/README.solaris2 between version 1.1.1.1 and 1.1.1.2

version 1.1.1.1, 1999/11/27 10:58:32 version 1.1.1.2, 2000/12/01 14:48:28
Line 37  a thread stack.  If you know that you will only be run
Line 37  a thread stack.  If you know that you will only be run
 or later, it should be possible to fix this by compiling the collector  or later, it should be possible to fix this by compiling the collector
 with -DSOLARIS23_MPROTECT_BUG_FIXED.  with -DSOLARIS23_MPROTECT_BUG_FIXED.
   
 Jeremy Fitzhardinge points out that there is a problem with the dlopen  Since 5.0 alpha5, dlopen disables collection temporarily,
 replacement, in that startup code in the library is run while the allocation  unless USE_PROC_FOR_LIBRARIES is defined.  In some unlikely cases, this
 lock is held.  This appears to be difficult to fix, since the collector does  can result in unpleasant heap growth.  But it seems better than the
 look at data structures maintained by dlopen, and hence some locking is needed  race/deadlock issues we had before.
 around the dlopen call.  Defining USE_PROC_FOR_LIBRARIES will get address  
 space layout information from /proc avoiding the dlopen lock.  But this has  
 other disadvanatages, e.g. mmapped files may be scanned.  
   
 If solaris_threads are used on an X86 processor with malloc redirected to  If solaris_threads are used on an X86 processor with malloc redirected to
 GC_malloc, it is necessary to call GC_thr_init explicitly before forking the  GC_malloc, it is necessary to call GC_thr_init explicitly before forking the

Legend:
Removed from v.1.1.1.1  
changed lines
  Added in v.1.1.1.2

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>