1 |
12 |
jlechner |
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.)
|