2011-05-20 Ivan Maidanski <ivmai@mail.ru>

	* doc/README.solaris2: Update.

diff --git a/ChangeLog b/ChangeLog
index fc728d084cb01c273a9666c56d246fc02cd2635c..041cce51746410863c88c4b71d3627fe0cb193d1 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2011-05-20  Ivan Maidanski  <ivmai@mail.ru>
+
+       * doc/README.solaris2: Update.
+
 2011-05-19  Ivan Maidanski  <ivmai@mail.ru> (really Jie Liu)
 
        * include/private/gcconfig.h (end, InitStackBottom): Declare

diff --git a/doc/README.solaris2 b/doc/README.solaris2
index f91410633c872572bce52d393d9dc78b2075b49f..d5716e4f5c7b6cf4baac6f2a4a6e1fced95668e2 100644 (file)
--- a/doc/README.solaris2
+++ b/doc/README.solaris2
@@ -13,7 +13,7 @@ not safe: "Many library routines use malloc() internally, so use brk()
 and sbrk() only when you know  that malloc() definitely will not be used by
 any library routine."  This doesn't make a lot of sense to me, since there
 seems to be no documentation as to which routines can transitively call malloc.
-Nonetheless, under Solaris2, the collector now (since 4.12) allocates
+Nonetheless, under Solaris2, the collector now allocates
 memory using mmap by default.  (It defines USE_MMAP in gcconfig.h.)
 You may want to reverse this decisions if you use -DREDIRECT_MALLOC=...
 
@@ -24,21 +24,19 @@ The collector must be compiled with -DGC_THREADS to be thread safe.
 This assumes use of the pthread_ interface.  Old style Solaris threads
 are no longer supported.
 
-It is also essential that gc.h be included in files that call thr_create,
-thr_join, thr_suspend, thr_continue, or dlopen.  Gc.h macro defines
-these to also do GC bookkeeping, etc.  Gc.h must be included with
-one or both of these macros defined, otherwise
-these replacements are not visible.
-A collector built in this way way only be used by programs that are
-linked with the threads library.
+It is also essential that gc.h be included in files that call pthread_create,
+pthread_join, pthread_detach, or dlopen.  gc.h macro defines these to also do
+GC bookkeeping, etc.  gc.h must be included with one or both of these macros
+defined, otherwise these replacements are not visible.  A collector built in
+this way way only be used by programs that are linked with the threads library.
 
 Since 5.0 alpha5, dlopen disables collection temporarily,
 unless USE_PROC_FOR_LIBRARIES is defined.  In some unlikely cases, this
 can result in unpleasant heap growth.  But it seems better than the
 race/deadlock issues we had before.
 
-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
+If threads are used on an X86 processor with malloc redirected to
+GC_malloc, it is necessary to call GC_INIT explicitly before forking the
 first thread.  (This avoids a deadlock arising from calling GC_thr_init
 with the allocation lock held.)
 
@@ -46,7 +44,7 @@ It appears that there is a problem in using gc_cpp.h in conjunction with
 Solaris threads and Sun's C++ runtime.  Apparently the overloaded new operator
 is invoked by some iostream initialization code before threads are correctly
 initialized.  As a result, call to thr_self() in garbage collector
-initialization  segfaults.  Currently the only known workaround is to not
+initialization  SEGV faults.  Currently the only known workaround is to not
 invoke the garbage collector from a user defined global operator new, or to
 have it invoke the garbage-collector's allocators only after main has started.
 (Note that the latter requires a moderately expensive test in operator