Mercurial > emacs
comparison gc/doc/README.solaris2 @ 51488:5de98dce4bd1
*** empty log message ***
author | Dave Love <fx@gnu.org> |
---|---|
date | Thu, 05 Jun 2003 17:49:22 +0000 |
parents | |
children |
comparison
equal
deleted
inserted
replaced
51487:01d68b199093 | 51488:5de98dce4bd1 |
---|---|
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 | |
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 Solaris2, the collector now (since 4.12) allocates | |
17 memory using mmap by default. (It defines USE_MMAP in gcconfig.h.) | |
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 -DGC_SOLARIS_THREADS (thr_ functions) | |
24 or -DGC_SOLARIS_PTHREADS (pthread_ functions) to be thread safe. | |
25 It is also essential that gc.h be included in files that call thr_create, | |
26 thr_join, thr_suspend, thr_continue, or dlopen. Gc.h macro defines | |
27 these to also do GC bookkeeping, etc. Gc.h must be included with | |
28 one or both of these macros defined, otherwise | |
29 these replacements are not visible. | |
30 A collector built in this way way only be used by programs that are | |
31 linked with the threads library. | |
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 Since 5.0 alpha5, dlopen disables collection temporarily, | |
41 unless USE_PROC_FOR_LIBRARIES is defined. In some unlikely cases, this | |
42 can result in unpleasant heap growth. But it seems better than the | |
43 race/deadlock issues we had before. | |
44 | |
45 If solaris_threads are used on an X86 processor with malloc redirected to | |
46 GC_malloc, it is necessary to call GC_thr_init explicitly before forking the | |
47 first thread. (This avoids a deadlock arising from calling GC_thr_init | |
48 with the allocation lock held.) | |
49 | |
50 It appears that there is a problem in using gc_cpp.h in conjunction with | |
51 Solaris threads and Sun's C++ runtime. Apparently the overloaded new operator | |
52 is invoked by some iostream initialization code before threads are correctly | |
53 initialized. As a result, call to thr_self() in garbage collector | |
54 initialization segfaults. Currently the only known workaround is to not | |
55 invoke the garbage collector from a user defined global operator new, or to | |
56 have it invoke the garbage-collector's allocators only after main has started. | |
57 (Note that the latter requires a moderately expensive test in operator | |
58 delete.) | |
59 | |
60 Hans-J. Boehm | |
61 (The above contains my personal opinions, which are probably not shared | |
62 by anyone else.) |