diff options
Diffstat (limited to 'boehm-gc/doc/README.environment')
-rw-r--r-- | boehm-gc/doc/README.environment | 151 |
1 files changed, 0 insertions, 151 deletions
diff --git a/boehm-gc/doc/README.environment b/boehm-gc/doc/README.environment deleted file mode 100644 index 686e948..0000000 --- a/boehm-gc/doc/README.environment +++ /dev/null @@ -1,151 +0,0 @@ -The garbage collector looks at a number of environment variables which are -then used to affect its operation. These are examined only on Un*x-like -platforms and win32. - -GC_INITIAL_HEAP_SIZE=<bytes> - Initial heap size in bytes. May speed up - process start-up. - -GC_MAXIMUM_HEAP_SIZE=<bytes> - Maximum collected heap size. - -GC_LOOP_ON_ABORT - Causes the collector abort routine to enter a tight loop. - This may make it easier to debug, such a process, especially - for multithreaded platforms that don't produce usable core - files, or if a core file would be too large. On some - platforms, this also causes SIGSEGV to be caught and - result in an infinite loop in a handler, allowing - similar debugging techniques. - -GC_PRINT_STATS - Turn on as much logging as is easily feasible without - adding signifcant runtime overhead. Doesn't work if - the collector is built with SMALL_CONFIG. Overridden - by setting GC_quiet. On by default if the collector - was built without -DSILENT. - -GC_DUMP_REGULARLY - Generate a GC debugging dump GC_dump() on startup - and during every collection. Very verbose. Useful - if you have a bug to report, but please include only the - last complete dump. - -GC_BACKTRACES=<n> - Generate n random backtraces (for heap profiling) after - each GC. Collector must have been built with - KEEP_BACK_PTRS. This won't generate useful output unless - most objects in the heap were allocated through debug - allocators. This is intended to be only a statistical - sample; individual traces may be erroneous due to - concurrent heap mutation. - -GC_PRINT_ADDRESS_MAP - Linux only. Dump /proc/self/maps, i.e. various address - maps for the process, to stderr on every GC. Useful for - mapping root addresses to source for deciphering leak - reports. - -GC_NPROCS=<n> - Linux w/threads only. Explicitly sets the number of processors - that the GC should expect to use. Note that setting this to 1 - when multiple processors are available will preserve - correctness, but may lead to really horrible performance, - since the lock implementation will immediately yield without - first spinning. - -GC_MARKERS=<n> - Linux w/threads and parallel marker only. Set the number - of marker threads. This is normaly set to the number of - processors. It is safer to adjust GC_MARKERS than GC_NPROCS, - since GC_MARKERS has no impact on the lock implementation. - -GC_NO_BLACKLIST_WARNING - Prevents the collector from issuing - warnings about allocations of very large blocks. - Deprecated. Use GC_LARGE_ALLOC_WARN_INTERVAL instead. - -GC_LARGE_ALLOC_WARN_INTERVAL=<n> - Print every nth warning about very large - block allocations, starting with the nth one. Small values - of n are generally benign, in that a bounded number of - such warnings generally indicate at most a bounded leak. - For best results it should be set at 1 during testing. - Default is 5. Very large numbers effectively disable the - warning. - -GC_IGNORE_GCJ_INFO - Ignore the type descriptors implicitly supplied by - GC_gcj_malloc and friends. This is useful for debugging - descriptor generation problems, and possibly for - temporarily working around such problems. It forces a - fully conservative scan of all heap objects except - those known to be pointerfree, and may thus have other - adverse effects. - -GC_PRINT_BACK_HEIGHT - Print max length of chain through unreachable objects - ending in a reachable one. If this number remains - bounded, then the program is "GC robust". This ensures - that a fixed number of misidentified pointers can only - result in a bounded space leak. This currently only - works if debugging allocation is used throughout. - It increases GC space and time requirements appreciably. - This feature is still somewhat experimental, and requires - that the collector have been built with MAKE_BACK_GRAPH - defined. For details, see Boehm, "Bounding Space Usage - of Conservative Garbage Collectors", POPL 2001, or - http://lib.hpl.hp.com/techpubs/2001/HPL-2001-251.html . - -GC_RETRY_SIGNALS, GC_NO_RETRY_SIGNALS - Try to compensate for lost - thread suspend signals in linux_threads.c. On by - default for GC_OSF1_THREADS, off otherwise. Note - that this does not work around a possible loss of - thread restart signals. This seems to be necessary for - some versions of Tru64. Since we've previously seen - similar issues on some other operating systems, it - was turned into a runtime flag to enable last-minute - work-arounds. - -GC_IGNORE_FB[=<n>] - (Win32 only.) Try to avoid treating a mapped - frame buffer as part of the root set. Certain (higher end?) - graphics cards seems to result in the graphics memory mapped - into the user address space as writable memory. - Unfortunately, there seems to be no systematic way to - identify such memory. Setting the environment variable to n - causes the collector to ignore mappings longer than n MB. - The default value of n is currently 15. (This should cover - a 16 MB graphics card, since the mapping appears to be slightly - shorter than all of graphics memory. It will fail if a dll - writes pointers to collectable objects into a data segment - whose length is >= 15MB. Empirically that's rare, but - certainly possible.) WARNING: Security sensitive applications - should probably disable this feature by setting - GC_disallow_ignore_fb, or by building with -DNO_GETENV, - since small values could force collection of reachable - objects, which is conceivably a (difficult to exploit) - security hole. GC_IGNORE_FB values less than 3 MB - are never honored, eliminating this risk for most, - but not all, applications. This feature is likely to disappear - if/when we find a less disgusting "solution". - IN VERSION 6.4 AND LATER, THIS SHOULD BE UNNECESSARY. - -The following turn on runtime flags that are also program settable. Checked -only during initialization. We expect that they will usually be set through -other means, but this may help with debugging and testing: - -GC_ENABLE_INCREMENTAL - Turn on incremental collection at startup. Note that, - depending on platform and collector configuration, this - may involve write protecting pieces of the heap to - track modifications. These pieces may include pointerfree - objects or not. Although this is intended to be - transparent, it may cause unintended system call failures. - Use with caution. - -GC_PAUSE_TIME_TARGET - Set the desired garbage collector pause time in msecs. - This only has an effect if incremental collection is - enabled. If a collection requires appreciably more time - than this, the client will be restarted, and the collector - will need to do additional work to compensate. The - special value "999999" indicates that pause time is - unlimited, and the incremental collector will behave - completely like a simple generational collector. If - the collector is configured for parallel marking, and - run on a multiprocessor, incremental collection should - only be used with unlimited pause time. - -GC_FIND_LEAK - Turns on GC_find_leak and thus leak detection. Forces a - collection at program termination to detect leaks that would - otherwise occur after the last GC. - -GC_ALL_INTERIOR_POINTERS - Turns on GC_all_interior_pointers and thus interior - pointer recognition. - -GC_DONT_GC - Turns off garbage collection. Use cautiously. |