1 The collector supports both incremental collection and threads under
2 Solaris. 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 Solaris, the collector now allocates memory using mmap by
17 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 (e.g., 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 Unless --disable-threads option is given, threads support is on by default in
28 configure. This causes the collector to be compiled with -D GC_THREADS
29 ensuring thread safety. This assumes use of the pthread_ interface; old-style
30 Solaris threads are no longer supported. Thread-local allocation is on by
31 default. Parallel marking is on by default (it could be disabled manually
32 by configure --disable-parallel-mark option).
33 34 It is also essential that gc.h be included in files that call pthread_create,
35 pthread_join, pthread_detach, or dlopen. gc.h macro defines these to also do
36 GC bookkeeping, etc. gc.h must be included with GC_THREADS macro defined
37 first, otherwise these replacements are not visible. A collector built in
38 this way may only be used by programs that are linked with the threads library.
39 40 Unless USE_PROC_FOR_LIBRARIES is defined, dlopen disables collection
41 temporarily. In some unlikely cases, this can result in unpleasant heap
42 growth. But it seems better than the race/deadlock issues we had before.
43 44 If threads are used on an i686 or x86_64 processor with malloc redirected to
45 GC_malloc, it is necessary to call GC_INIT explicitly before forking the
46 first thread. (This avoids a deadlock arising from calling GC_thr_init
47 with the allocator lock held.)
48 49 There could be an issue when using gc_cpp.h in conjunction with Solaris
50 threads and Sun's C++ runtime. Apparently the overloaded new operator
51 may be invoked by some iostream initialization code before threads are
52 correctly initialized. This may cause a SIGSEGV during initialization
53 of the garbage collector. Currently the only known workaround is to not
54 invoke the garbage collector from a user defined global operator new, or to
55 have it invoke the garbage-collector's allocators only after main has started.
56 (Note that the latter requires a moderately expensive test in operator
57 delete.)
58 59 I encountered "symbol <unknown>: offset .... is non-aligned" errors. These
60 appear to be traceable to the use of the GNU assembler with the Sun linker.
61 The former appears to generate a relocation not understood by the latter.
62 The fix appears to be to use a consistent toolchain. (As a non-Solaris-expert
63 my solution involved hacking the libtool script, but I'm sure you can
64 do something less ugly.)
65 66 Hans-J. Boehm
67 (The above contains my personal opinions, which are probably not shared
68 by anyone else.)
69