1 Performance of the incremental collector can be greatly enhanced with
2 -DNO_EXECUTE_PERMISSION.
3 4 The collector should run with all of the -32, -n32 and -64 ABIs. Remember to
5 define the AS macro in the Makefile.direct to be "as -64", or "as -n32".
6 7 If you use -DREDIRECT_MALLOC=GC_malloc with C++ code, your code should make
8 at least one explicit call to malloc instead of new to ensure that the proper
9 version of malloc is linked in.
10 11 Sproc threads are not supported.
12 13 Pthreads support is provided. This requires that:
14 15 1) You compile the collector with -DGC_THREADS specified in Makefile.direct.
16 17 2) You have the latest pthreads patches installed.
18 19 (Though the collector makes only documented pthread calls,
20 it relies on signal/threads interactions working just right in ways
21 that are not required by the standard. It is unlikely that this code
22 will run on other pthreads platforms. But please tell me if it does.)
23 24 3) Every file that makes thread calls should define GC_THREADS and then
25 include gc.h. Gc.h redefines some of the pthread primitives as macros which
26 also provide the collector with information it requires.
27 28 4) pthread_cond_wait and pthread_cond_timedwait should be prepared for
29 premature wakeups. (I believe the pthreads and related standards require this
30 anyway. Irix pthreads often terminate a wait if a signal arrives.
31 The garbage collector uses signals to stop threads.)
32 33 5) It is expensive to stop a thread waiting in IO at the time the request is
34 initiated. Applications with many such threads may not exhibit acceptable
35 performance with the collector. (Increasing the heap size may help.)
36 37 6) The collector should not be compiled with -DREDIRECT_MALLOC. This
38 confuses some library calls made by the pthreads implementation, which
39 expect the standard malloc.
40