diff options
| -rw-r--r-- | Makefile.am | 1 | ||||
| -rw-r--r-- | doc/faq.html | 138 | ||||
| -rw-r--r-- | doc/overview.md | 4 |
3 files changed, 141 insertions, 2 deletions
diff --git a/Makefile.am b/Makefile.am index b09ef122..0ca81e83 100644 --- a/Makefile.am +++ b/Makefile.am @@ -240,6 +240,7 @@ dist_doc_DATA = \ doc/README.environment \ doc/README.macros \ doc/debugging.md \ + doc/faq.html \ doc/finalization.md \ doc/gcdescr.md \ doc/gcinterface.md \ diff --git a/doc/faq.html b/doc/faq.html new file mode 100644 index 00000000..941d81ba --- /dev/null +++ b/doc/faq.html @@ -0,0 +1,138 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> +<HEAD> +<TITLE>FAQ: A garbage collector for C and C++</title> +</head> +<BODY> +<H1>FAQ: A garbage collector for C and C++</h1> +This is the beginning of a "frequently asked questions" file for what +has become known as the "Boehm-Demers-Weiser" garbage collector. +Some of these are likely to apply to any garbage collector whatsoever. +<P> +<B>I wrote a test program which allocates objects and registers +finalizers for them. Only a few (or no) objects are finalized. +What's wrong?</b> +<P> +Probably nothing. Finalizers are only executed if all of +the following happen before the process exits: +<UL> +<LI> A garbage collection runs. This normally happens only after +a significant amount of allocation. +<LI> The objects in question appear inaccessible at the time of +the collection. It is common for a handful of objects to appear +accessible even though they shouldn't be, e.g. because temporary +pointers to them haven't yet been overwritten. Also +note that by default only the first item in a chain of finalizable +objects will be finalized in a collection. +<LI> Another GC_ call notices that there are finalizers waiting +to be run and does so. +</ul> +Small test programs typically don't run long enough for this to +happen. +<P> +<B>Does this mean that the collector might leak memory?</b> +<P> +In the short term yes. But it is unlikely, though not impossible, +that this will result in a leak that grows over time. Under normal +circumstances, short term, or one time leaks are a minor issue. +Memory leaks in explicitly managed programs are feared because they +almost always continue to grow over time. +<P> +For (a lot) more details see: +<P> +``Bounding Space Usage of Conservative Garbage Collectors'', +<I>Proceedings of the 2002 ACM SIGPLAN-SIGACT Symposium on Principles of +Programming Languages</i>, Jan. 2002, pp. 93-100. +<A HREF="http://portal.acm.org/citation.cfm?doid=503272.503282"> +Official version.</a> +<A HREF="http://www.hpl.hp.com/techreports/2001/HPL-2001-251.html"> +Technical report version.</a> +<P> +<B>How can I get more of the finalizers to run to convince myself that +the GC is working?</b> +<P> +Invoke GC_gcollect a couple of times just before process exit. +<P> +<B>I want to ensure that all my objects are finalized and reclaimed before +process exit. How can I do that?</b> +<P> +You can't, and you don't really want that. +This would require finalizing <I>reachable</i> objects. +Finalizers run later would have to be able to handle this, and would have +to be able to run with randomly broken libraries, because the objects +they rely on where previously finalized. In most environments, you +would also be replacing the operating systems mechanism for very +efficiently reclaiming process memory at process exit with a significantly +slower mechanism. +<P> +You do sometimes want to ensure that certain particular resources are +explicitly reclaimed before process exit, whether or not they become +unreachable. Programming techniques for ensuring this are discussed in +<P> +``Destructors, Finalizers, and Synchronization'', +<I>Proceeedings of the 2003 ACM SIGPLAN-SIGACT Symposium on Principles of +Programming Languages</i>, Jan. 2003, pp. 262-272. +<A HREF="http://portal.acm.org/citation.cfm?doid=604131.604153"> +Official version.</a> +<A HREF="http://www.hpl.hp.com/techreports/2002/HPL-2002-335.html"> +Technical report version.</a> +<A HREF="../popl03/web/index.html">HTML slides.</a> +<A HREF="../popl03/slides.pdf">PDF slides.</a> +<P> +<B>I wrote a memory allocation loop, and it runs <I>much</i> slower +with the garbage collector than when I use <TT>malloc</tt>/<TT>free</tt> +memory management. Why?</b> +<P> +Odds are your loop allocates very large objects and never initializes +them. Real programs generally don't behave that way. Garbage collectors +generally perform appreciably worse for large object allocations, +and they generally initialize objects, even if you don't. +<P> +<B>What can I do to maximize allocation performance?</b> +<P> +Here are some hints: +<UL> +<LI> Use <TT>GC_MALLOC_ATOMIC</tt> where possible. +<LI> For a multithreaded application, take advantage of +<TT>gc_local_alloc.h</tt> to avoid locking on each allocation. +<LI> For a single-threaded application, use a GC library without +thread support. If this is inconvenient, use <TT>gc_local_alloc.h</tt>. +<LI> If you use large statically allocated arrays or mapped files, +consider <TT>GC_exclude_static_roots</tt>. +</ul> +<P> +<B>If my heap uses 2 GB on a 32-bit machine, won't every other +integer or other random data be misinterpreted as a pointer by the +collector? Thus won't way too much memory be retained?</b> +<P> +Maybe. Probably, if the collector is used purely conservatively, +with no pointer layout information (such as use of +<TT>GC_MALLOC_ATOMIC</tt>). +<P> +With a gigabyte heap, you are clearly much better off on a 64-bit +machine. Empirical evidence seems to suggest that some such applications +work on a 32-bit machine, and others don't perform acceptably. +<P> +Simple probability calculations for pointer misidentifications +are generally incorrect. +The probability of misinterpreting an integer is typically reduced +significantly by +a number of collector features and fortunate accidents. Most integers +are small, and small integers can generally not be heap addresses. +The collector black-listing mechanism avoids allocating +areas that are prone to be targets of misinterpreted references. +The collector can be told to ignore some or all pointers to object +interiors. +<P> +<B>I have a different question that isn't answered here, nor in +<A HREF="http://hboehm.info/gc">the other GC +documentation</a>. Where else can I go?</b> +<P> +You may want to check +<A HREF="https://lists.opendylan.org/pipermail/bdwgc/"> +the GC mailing list archives</a>. +If you can't find the answer there, please post your question to +<A HREF="mailto:bdwgc@lists.opendylan.org">the GC mailing list</a>. +If you are not subscribed to the mailing lists, your posting may +take a while to appear, since such postings are moderated. +</body> +</html> diff --git a/doc/overview.md b/doc/overview.md index 13e553dd..d0182f42 100644 --- a/doc/overview.md +++ b/doc/overview.md @@ -1,4 +1,4 @@ -[Interface Overview](gcinterface.md) | [Tutorial Slides](http://www.hboehm.info/gc/04tutorial.pdf) | [FAQ](http://www.hboehm.info/gc/faq.html) | [Example](simple_example.md) | [Download](https://github.com/ivmai/bdwgc/wiki/Download) +[Interface Overview](gcinterface.md) | [Tutorial Slides](http://www.hboehm.info/gc/04tutorial.pdf) | [FAQ](faq.html) | [Example](simple_example.md) | [Download](https://github.com/ivmai/bdwgc/wiki/Download) ---|---|---|---|--- # A garbage collector for C and C++ @@ -225,7 +225,7 @@ Slides for Hans Boehm's [Slides from an ISMM 2004 tutorial about the GC](http://www.hboehm.info/gc/04tutorial.pdf). -[A FAQ (frequently asked questions) list](http://www.hboehm.info/gc/faq.html). +[A FAQ (frequently asked questions) list](faq.html). [Directory](http://www.hboehm.info/gc/gc_source/) containing the distribution files of all garbage collector releases. It duplicates |