]>
Commit | Line | Data |
---|---|---|
73ffefd0 TT |
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 | |
20bbd3cd | 4 | (by defining MPROTECT_VDB instead of PROC_VDB in gcconfig.h) to use mprotect |
73ffefd0 TT |
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 (since 4.12) allocates | |
20bbd3cd | 17 | memory using mmap by default. (It defines USE_MMAP in gcconfig.h.) |
73ffefd0 TT |
18 | You may want to reverse this decisions if you use -DREDIRECT_MALLOC=... |
19 | ||
20 | ||
21 | SOLARIS THREADS: | |
22 | ||
23 | The collector must be compiled with -DSOLARIS_THREADS to be thread safe. | |
24 | It is also essential that gc.h be included in files that call thr_create, | |
25 | thr_join, thr_suspend, thr_continue, or dlopen. Gc.h macro defines | |
26 | these to also do GC bookkeeping, etc. Gc.h must be included with | |
27 | SOLARIS_THREADS defined, otherwise these replacements are not visible. | |
28 | A collector built in this way way only be used by programs that are | |
29 | linked with the threads library. | |
30 | ||
31 | If you are using the Pthreads interface, also define _SOLARIS_PTHREADS. | |
32 | ||
33 | In this mode, the collector contains various workarounds for older Solaris | |
34 | bugs. Mostly, these should not be noticeable unless you look at system | |
35 | call traces. However, it cannot protect a guard page at the end of | |
36 | a thread stack. If you know that you will only be running Solaris2.5 | |
37 | or later, it should be possible to fix this by compiling the collector | |
38 | with -DSOLARIS23_MPROTECT_BUG_FIXED. | |
39 | ||
40 | Jeremy Fitzhardinge points out that there is a problem with the dlopen | |
41 | replacement, in that startup code in the library is run while the allocation | |
42 | lock is held. This appears to be difficult to fix, since the collector does | |
43 | look at data structures maintained by dlopen, and hence some locking is needed | |
44 | around the dlopen call. Defining USE_PROC_FOR_LIBRARIES will get address | |
45 | space layout information from /proc avoiding the dlopen lock. But this has | |
46 | other disadvanatages, e.g. mmapped files may be scanned. | |
47 | ||
48 | If solaris_threads are used on an X86 processor with malloc redirected to | |
49 | GC_malloc, it is necessary to call GC_thr_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 segfaults. 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 | Hans-J. Boehm | |
64 | (The above contains my personal opinions, which are probably not shared | |
65 | by anyone else.) |