OpenCores
URL https://opencores.org/ocsvn/openrisc/openrisc/trunk

Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [gnu-dev/] [or1k-gcc/] [boehm-gc/] [doc/] [README.solaris2] - Blame information for rev 721

Details | Compare with Previous | View Log

Line No. Rev Author Line
1 721 jeremybenn
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 a deadlock is likely to result.
47
 
48
It appears that there is a problem in using gc_cpp.h in conjunction with
49
Solaris threads and Sun's C++ runtime.  Apparently the overloaded new operator
50
is invoked by some iostream initialization code before threads are correctly
51
initialized.  As a result, call to thr_self() in garbage collector
52
initialization  segfaults.  Currently the only known workaround is to not
53
invoke the garbage collector from a user defined global operator new, or to
54
have it invoke the garbage-collector's allocators only after main has started.
55
(Note that the latter requires a moderately expensive test in operator
56
delete.)
57
 
58
Hans-J. Boehm
59
(The above contains my personal opinions, which are probably not shared
60
by anyone else.)

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.