diff options
Diffstat (limited to 'boehm-gc/doc/README.solaris2')
| -rw-r--r-- | boehm-gc/doc/README.solaris2 | 50 |
1 files changed, 30 insertions, 20 deletions
diff --git a/boehm-gc/doc/README.solaris2 b/boehm-gc/doc/README.solaris2 index 6ed61dc83dc..2f3b511aee5 100644 --- a/boehm-gc/doc/README.solaris2 +++ b/boehm-gc/doc/README.solaris2 @@ -13,37 +13,40 @@ 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=... +Note: +Before you run "make check", you need to set your LD_LIBRARY_PATH correctly +(eg., to "/usr/local/lib") so that tests can find the shared library +libgcc_s.so.1. Alternatively, you can configure with --disable-shared. SOLARIS THREADS: -The collector must be compiled with -DGC_SOLARIS_THREADS (thr_ functions) -or -DGC_SOLARIS_PTHREADS (pthread_ functions) to be thread safe. -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. - -In this mode, the collector contains various workarounds for older Solaris -bugs. Mostly, these should not be noticeable unless you look at system -call traces. However, it cannot protect a guard page at the end of -a thread stack. If you know that you will only be running Solaris2.5 -or later, it should be possible to fix this by compiling the collector -with -DSOLARIS23_MPROTECT_BUG_FIXED. +Threads support is enabled by configure "--enable-threads=posix" option. +(In case of GCC compiler, multi-threading support is on by default.) +This causes the collector to be compiled with -D GC_THREADS (or +-D GC_SOLARIS_THREADS) ensuring thread safety. +This assumes use of the pthread_ interface. Old style Solaris threads +are no longer supported. +Thread-local allocation is now on by default. Parallel marking is on by +default starting from GC v7.3 but it could be enabled or disabled manually +by the corresponding "--enable/disable-parallel-mark" options. + +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.) @@ -51,12 +54,19 @@ 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 delete.) +I encountered "symbol <unknown>: offet .... is non-aligned" errors. These +appear to be traceable to the use of the GNU assembler with the Sun linker. +The former appears to generate a relocation not understood by the latter. +The fix appears to be to use a consistent tool chain. (As a non-Solaris-expert +my solution involved hacking the libtool script, but I'm sure you can +do something less ugly.) + Hans-J. Boehm (The above contains my personal opinions, which are probably not shared by anyone else.) |