PageRenderTime 42ms CodeModel.GetById 12ms app.highlight 18ms RepoModel.GetById 2ms app.codeStats 0ms

/vendor/gc/doc/overview.html

http://github.com/feyeleanor/RubyGoLightly
HTML | 446 lines | 443 code | 3 blank | 0 comment | 0 complexity | 4b19920f41f573772580e46ca118040c MD5 | raw file
  1<!DOCTYPE HTML>
  2<html><head><title>A garbage collector for C and C++</title></head>
  3<body>
  4<table bgcolor="#f0f0ff" cellpadding="10%">
  5  <tbody><tr>
  6  <td><a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcinterface.html">Interface Overview</a></td>
  7  <td><a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/04tutorial.pdf">Tutorial Slides</a></td>
  8  <td><a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/faq.html">FAQ</a></td>
  9  <td><a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/simple_example.html">Example</a></td>
 10  <td><a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source">Download</a></td>
 11  <td><a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/license.txt">License</a></td>
 12  </tr>
 13</tbody></table>
 14<h1>A garbage collector for C and C++</h1>
 15<ul>
 16<li><a href="#platforms">Platforms</a>
 17</li><li><a href="#multiprocessors">Scalable multiprocessor versions</a>
 18</li><li><a href="#details">Some collector details</a>
 19</li><li><a href="#further">Further reading</a>
 20</li><li><a href="#users">Current users</a>
 21</li><li><a href="#collector">Local Links for this collector</a>
 22</li><li><a href="#background">Local Background Links</a>
 23</li><li><a href="#contacts">Contacts and Mailing List</a>
 24</li></ul>
 25[ This is an updated version of the page formerly at
 26<tt>http://reality.sgi.com/boehm/gc.html</tt>
 27and before that at
 28<a href="ftp://parcftp.xerox.com/pub/gc/gc.html">
 29<tt>ftp://parcftp.xerox.com/pub/gc/gc.html</tt></a>.]
 30<p>
 31The <a href="http://www.hpl.hp.com/personal/Hans_Boehm">Boehm</a>-<a href="http://www.cs.cornell.edu/annual_report/00-01/bios.htm#demers">Demers</a>-<a href="http://www-sul.stanford.edu/weiser/">Weiser</a>
 32conservative garbage collector can
 33be used as a garbage collecting
 34replacement for C <tt>malloc</tt> or C++ <tt>new</tt>.
 35It allows you to allocate memory basically as you normally would,
 36without explicitly deallocating memory that is no longer useful.
 37The collector automatically recycles memory when it determines
 38that it can no longer be otherwise accessed.
 39A simple example of such a use is given
 40<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/simple_example.html">here</a>.
 41</p><p>
 42The collector is also used by a number of programming language
 43implementations that either use C as intermediate code, want
 44to facilitate easier interoperation with C libraries, or
 45just prefer the simple collector interface.
 46For a more detailed description of the interface, see
 47<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcinterface.html">here</a>.
 48</p><p>
 49Alternatively, the garbage collector  may be used as
 50a <a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/leak.html">leak detector</a>
 51for C or C++ programs, though that is not its primary goal.
 52</p><p>
 53Typically several versions will be available.
 54Usually you should first try to use
 55<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc.tar.gz"><tt>gc_source/gc.tar.gz</tt></a>,
 56which is normally an older, more stable version.
 57</p><p>
 58If that fails, try the latest explicitly numbered version
 59in <a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/">
 60<tt>gc_source/</tt></a>.
 61Later versions may contain additional features, platform support,
 62or bug fixes, but are likely to be less well tested.
 63Note that versions containing the letters <tt>alpha</tt> are even less
 64well tested than others, especially on non-HP platforms.
 65</p><p>
 66A slightly older version of the garbage collector is now also
 67included as part of the
 68<a href="http://gcc.gnu.org/">GNU compiler</a>
 69distribution.  The source
 70code for that version is available for browsing
 71<a href="http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/boehm-gc/">here</a>.
 72</p><p>
 73The arguments for and against conservative garbage collection
 74in C and C++ are briefly
 75discussed in
 76<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/issues.html">issues.html</a>.  The beginnings of
 77a frequently-asked-questions list are <a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/faq.html">here</a>.
 78</p><p>
 79The garbage collector code is copyrighted by
 80<a href="http://www.hpl.hp.com/personal/Hans_Boehm">Hans-J. Boehm</a>,
 81Alan J. Demers,
 82<a href="http://www.xerox.com/">Xerox Corporation</a>,
 83<a href="http://www.sgi.com/">Silicon Graphics</a>,
 84and
 85<a href="http://www.hp.com/">Hewlett-Packard Company</a>.
 86It may be used and copied without payment of a fee under minimal restrictions.
 87See the README file in the distribution  or the
 88<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/license.txt">license</a> for more details.
 89<b>IT IS PROVIDED AS IS,
 90WITH ABSOLUTELY NO WARRANTY EXPRESSED OR IMPLIED.  ANY USE IS AT YOUR OWN RISK</b>.
 91</p><p>
 92Empirically, this collector works with most unmodified C programs,
 93simply by replacing
 94<tt>malloc</tt> with <tt>GC_malloc</tt> calls,
 95replacing <tt>realloc</tt> with <tt>GC_realloc</tt> calls, and removing
 96free calls.  Exceptions are discussed
 97in <a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/issues.html">issues.html</a>. 
 98</p><h2><a name="platforms">Platforms</a></h2>
 99The collector is not completely portable, but the distribution
100includes ports to most standard PC and UNIX/Linux platforms.
101The collector should work on Linux, *BSD, recent Windows versions,
102MacOS X, HP/UX, Solaris,
103Tru64, Irix and a few other operating systems.
104Some ports are more polished than others.
105<p>
106Irix pthreads, Linux threads, Win32 threads, Solaris threads
107(old style and pthreads),
108HP/UX 11 pthreads, Tru64 pthreads, and MacOS X threads are supported
109in recent versions.
110</p><h3>Separately distributed ports</h3>
111For MacOS 9/Classic use, Patrick Beard's latest port is available from
112<a href="http://homepage.mac.com/pcbeard/gc/">
113<tt>http://homepage.mac.com/pcbeard/gc/</tt></a>.
114(Unfortunately, that's now quite dated.
115I'm not in a position to test under MacOS.  Although I try to
116incorporate changes, it is impossible for
117me to update the project file.)
118<p>
119Precompiled versions of the collector for NetBSD are available
120<a href="ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/devel/boehm-gc/README.html">here</a>
121or
122<a href="http://www.netbsd.org/packages/devel/boehm-gc/README.html">here</a>.
123</p><p>
124<a href="http://www.debian.org/">Debian Linux</a> includes prepackaged
125versions of the collector.
126</p><h2><a name="multiprocessors">Scalable multiprocessor versions</a></h2>
127Kenjiro Taura, Toshio Endo, and Akinori Yonezawa have made available
128a <a href="http://www.yl.is.s.u-tokyo.ac.jp/gc/">parallel collector</a>
129based on this one.  Their collector takes advantage of multiple processors
130during a collection.  Starting with collector version 6.0alpha1
131we also do this, though with more modest processor scalability goals.
132Our approach is discussed briefly in
133<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/scale.html"><tt>scale.html</tt></a>.
134<h2><a name="details">Some Collector Details</a></h2>
135The collector uses a <a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/complexity.html">mark-sweep</a> algorithm.
136It provides incremental and generational
137collection under operating systems which provide the right kind of
138virtual memory support.  (Currently this includes SunOS[45], IRIX,
139OSF/1, Linux, and Windows, with varying restrictions.)
140It allows <a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/finalization.html"><i>finalization</i></a> code
141to be invoked when an object is collected.
142It can take advantage of type information to locate pointers if such
143information is provided, but it is usually used without such information.
144ee the README and
145<tt>gc.h</tt> files in the distribution for more details.
146<p>
147For an overview of the implementation, see <a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html">here</a>.
148</p><p>
149The garbage collector distribution includes a C string
150(<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/cordh.txt"><i>cord</i></a>) package that provides
151for fast concatenation and substring operations on long strings.
152A simple curses- and win32-based editor that represents the entire file
153as a cord is included as a
154sample application.
155</p><p>
156Performance of the nonincremental collector is typically competitive
157with malloc/free implementations.  Both space and time overhead are
158likely to be only slightly higher
159for programs written for malloc/free
160(see Detlefs, Dosser and Zorn's
161<a href="ftp://ftp.cs.colorado.edu/pub/techreports/zorn/CU-CS-665-93.ps.Z">Memory Allocation Costs in Large C and C++ Programs</a>.)
162For programs allocating primarily very small objects, the collector
163may be faster; for programs allocating primarily large objects it will
164be slower.  If the collector is used in a multithreaded environment
165and configured for thread-local allocation, it may in some cases
166significantly outperform malloc/free allocation in time.
167</p><p>
168We also expect that in many cases any additional overhead
169will be more than compensated for by decreased copying etc.
170if programs are written
171and tuned for garbage collection.
172</p><h1><a name="further">Further Reading:</a></h1>
173<b>The beginnings of a frequently asked questions list for this
174collector are <a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/faq.html">here</a></b>.
175<p>
176<b>The following provide information on garbage collection in general</b>:
177</p><p>
178Paul Wilson's <a href="ftp://ftp.cs.utexas.edu/pub/garbage">garbage collection ftp archive</a> and <a href="ftp://ftp.cs.utexas.edu/pub/garbage/gcsurvey.ps">GC survey</a>.
179</p><p>
180The Ravenbrook <a href="http://www.memorymanagement.org/">
181Memory Management Reference</a>.
182</p><p>
183David Chase's
184<a href="http://www.iecc.com/gclist/GC-faq.html">GC FAQ</a>.
185</p><p>
186Richard Jones'
187<a href="http://www.ukc.ac.uk/computer_science/Html/Jones/gc.html">
188GC page</a> and
189<a href="http://www.cs.kent.ac.uk/people/staff/rej/gcbook/gcbook.html">
190his book</a>.
191</p><p>
192<b>The following papers describe the collector algorithms we use
193and the underlying design decisions at
194a higher level.</b>
195</p><p>
196(Some of the lower level details can be found
197<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html">here</a>.)
198</p><p>
199The first one is not available
200electronically due to copyright considerations.  Most of the others are
201subject to ACM copyright.
202</p><p>
203Boehm, H., "Dynamic Memory Allocation and Garbage Collection", <i>Computers in Physics
2049</i>, 3, May/June 1995, pp. 297-303.  This is directed at an otherwise sophisticated
205audience unfamiliar with memory allocation issues.  The algorithmic details differ
206from those in the implementation.  There is a related letter to the editor and a minor
207correction in the next issue.
208</p><p>
209Boehm, H., and <a href="http://www.ubiq.com/hypertext/weiser/weiser.html">M. Weiser</a>,
210<a href="http://www.hpl.hp.com/personal/Hans_Boehm/spe_gc_paper">"Garbage Collection in an Uncooperative Environment"</a>,
211<i>Software Practice &amp; Experience</i>, September 1988, pp. 807-820.
212</p><p>
213Boehm, H., A. Demers, and S. Shenker, <a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/papers/pldi91.ps.Z">"Mostly Parallel Garbage Collection"</a>, Proceedings
214of the ACM SIGPLAN '91 Conference on Programming Language Design and Implementation,
215<i>SIGPLAN Notices 26</i>, 6 (June 1991), pp. 157-164.
216</p><p>
217Boehm, H., <a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/papers/pldi93.ps.Z">"Space Efficient Conservative Garbage Collection"</a>, Proceedings of the ACM
218SIGPLAN '93 Conference on Programming Language Design and Implementation, <i>SIGPLAN
219Notices 28</i>, 6 (June 1993), pp. 197-206.
220</p><p>
221Boehm, H., "Reducing Garbage Collector Cache Misses",
222<i> Proceedings of the 2000 International Symposium on Memory Management </i>.
223<a href="http://portal.acm.org/citation.cfm?doid=362422.362438">
224Official version.</a>
225<a href="http://www.hpl.hp.com/techreports/2000/HPL-2000-99.html">
226Technical report version.</a>  Describes the prefetch strategy
227incorporated into the collector for some platforms.  Explains why
228the sweep phase of a "mark-sweep" collector should not really be
229a distinct phase.
230</p><p>
231M. Serrano, H. Boehm,
232"Understanding Memory Allocation of Scheme Programs",
233<i>Proceedings of the Fifth ACM SIGPLAN International Conference on
234Functional Programming</i>, 2000, Montreal, Canada, pp. 245-256.
235<a href="http://www.acm.org/pubs/citations/proceedings/fp/351240/p245-serrano/">
236Official version.</a>
237<a href="http://www.hpl.hp.com/techreports/2000/HPL-2000-62.html">
238Earlier Technical Report version.</a>  Includes some discussion of the
239collector debugging facilities for identifying causes of memory retention.
240</p><p>
241Boehm, H.,
242"Fast Multiprocessor Memory Allocation and Garbage Collection",
243<a href="http://www.hpl.hp.com/techreports/2000/HPL-2000-165.html">
244HP Labs Technical Report HPL 2000-165</a>.  Discusses the parallel
245collection algorithms, and presents some performance results.
246</p><p>
247Boehm, H., "Bounding Space Usage of Conservative Garbage Collectors",
248<i>Proceeedings of the 2002 ACM SIGPLAN-SIGACT Symposium on Principles of
249Programming Languages</i>, Jan. 2002, pp. 93-100.
250<a href="http://portal.acm.org/citation.cfm?doid=503272.503282">
251Official version.</a>
252<a href="http://www.hpl.hp.com/techreports/2001/HPL-2001-251.html">
253Technical report version.</a>
254Includes a discussion of a collector facility to much more reliably test for
255the potential of unbounded heap growth.
256</p><p>
257<b>The following papers discuss language and compiler restrictions necessary to guaranteed
258safety of conservative garbage collection.</b>
259</p><p>
260We thank John Levine and JCLT for allowing
261us to make the second paper available electronically, and providing PostScript for the final
262version.
263</p><p>
264Boehm, H., <a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/papers/pldi96.ps.gz">``Simple
265Garbage-Collector-Safety''</a>, Proceedings
266of the ACM SIGPLAN '96 Conference on Programming Language Design
267and Implementation.
268</p><p>
269Boehm, H., and D. Chase,  <a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/papers/boecha.ps.gz">
270``A Proposal for Garbage-Collector-Safe C Compilation''</a>,
271<i>Journal of C  Language Translation 4</i>, 2 (Decemeber 1992), pp. 126-141.
272</p><p>
273<b>Other related information: </b>
274</p><p>
275The Detlefs, Dosser and Zorn's <a href="ftp://ftp.cs.colorado.edu/pub/techreports/zorn/CU-CS-665-93.ps.Z">Memory Allocation Costs in Large C and C++ Programs</a>.
276 This is a performance comparison of the Boehm-Demers-Weiser collector to malloc/free,
277using programs written for malloc/free.
278</p><p>
279Joel Bartlett's <a href="ftp://ftp.digital.com/pub/DEC/CCgc">mostly copying conservative garbage collector for C++</a>.
280</p><p>
281John Ellis and David Detlef's <a href="ftp://parcftp.xerox.com/pub/ellis/gc/gc.ps">Safe Efficient Garbage Collection for C++</a> proposal.
282</p><p>
283Henry Baker's <a href="http://home.pipeline.com/%7Ehbaker1/">paper collection</a>.
284</p><p>
285Slides for Hans Boehm's <a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/myths.ps">Allocation and GC Myths</a> talk.
286</p><h1><a name="users">Current users:</a></h1>
287Known current users of some variant of this collector include:
288<p>
289The runtime system for <a href="http://gcc.gnu.org/java">GCJ</a>,
290the static GNU java compiler.
291</p><p>
292<a href="http://w3m.sourceforge.net/">W3m</a>, a text-based web browser.
293</p><p>
294Some versions of the Xerox DocuPrint printer software.
295</p><p>
296The <a href="http://www.mozilla.org/">Mozilla</a> project, as leak
297detector.
298</p><p>
299The <a href="http://www.go-mono.com/">Mono</a> project,
300an open source implementation of the .NET development framework.
301</p><p>
302The <a href="http://www.gnu.org/projects/dotgnu/">DotGNU Portable.NET
303project</a>, another open source .NET implementation.
304</p><p>
305The <a href="http://irssi.org/">Irssi IRC client</a>.
306</p><p>
307<a href="http://titanium.cs.berkeley.edu/">The Berkeley Titanium project</a>.
308</p><p>
309<a href="http://www.nag.co.uk/nagware_fortran_compilers.asp">The NAGWare f90 Fortran 90 compiler</a>.
310</p><p>
311Elwood Corporation's <a href="http://www.elwood.com/eclipse-info/index.htm">
312Eclipse</a> Common Lisp system, C library, and translator.
313</p><p>
314The <a href="http://www-sop.inria.fr/mimosa/fp/Bigloo/">Bigloo
315Scheme</a>
316and <a href="http://kaolin.unice.fr/%7Eserrano/camloo.html">Camloo ML
317compilers</a>
318written by Manuel Serrano and others.
319</p><p>
320Brent Benson's <a href="http://ftp.cs.indiana.edu/pub/scheme-repository/imp/">libscheme</a>.
321</p><p>
322The <a href="http://www.cs.rice.edu/CS/PLT/packages/mzscheme/index.html">MzScheme</a> scheme implementation.
323</p><p>
324The <a href="http://www.cs.washington.edu/research/projects/cecil/www/cecil-home.html">University of Washington Cecil Implementation</a>.
325</p><p>
326<a href="http://www.icsi.berkeley.edu/Sather/">The Berkeley Sather implementation</a>.
327</p><p>
328<a href="http://www.cs.berkeley.edu/%7Eharmonia/">The Berkeley Harmonia Project</a>.
329</p><p>
330The <a href="http://www.cs.arizona.edu/sumatra/toba/">Toba</a> Java Virtual
331Machine to C translator.
332</p><p>
333The <a href="http://www.gwydiondylan.org/">Gwydion Dylan compiler</a>.
334</p><p>
335The <a href="http://gcc.gnu.org/onlinedocs/gcc/Objective-C.html">
336GNU Objective C runtime</a>.
337</p><p>
338<a href="http://www.math.uiuc.edu/Macaulay2">Macaulay 2</a>, a system to support
339research in algebraic geometry and commutative algebra.
340</p><p>
341The <a href="http://www.vestasys.org/">Vesta</a> configuration management
342system.
343</p><p>
344<a href="http://www.visual-prolog.com/vip6">Visual Prolog 6</a>.
345</p><p>
346<a href="http://asymptote.sf.net/">Asymptote LaTeX-compatible
347vector graphics language.</a>
348
349</p><h1><a name="collector">More collector information at this site</a></h1>
350<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/simple_example.html">A simple illustration of how to build and
351use the collector.</a>.
352<p>
353<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcinterface.html">Description of alternate interfaces to the
354garbage collector.</a>
355</p><p>
356<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/04tutorial.pdf">Slides from an ISMM 2004  tutorial about the GC.</a>
357</p><p>
358<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/faq.html">A FAQ (frequently asked questions) list.</a>
359</p><p>
360<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/leak.html">How to use the garbage collector as a leak detector.</a>
361</p><p>
362<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/debugging.html">Some hints on debugging garbage collected
363applications.</a>
364</p><p>
365<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/gcdescr.html">An overview of the implementation of the
366garbage collector.</a>
367</p><p>
368<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/tree.html">The data structure used for fast pointer lookups.</a>
369</p><p>
370<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/scale.html">Scalability of the collector to multiprocessors.</a>
371</p><p>
372<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source">Directory containing garbage collector source.</a>
373
374</p><h1><a name="background">More background information at this site</a></h1>
375<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/bounds.html">An attempt to establish a bound on space usage of
376conservative garbage collectors.</a>
377<p>
378<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/complexity.html">Mark-sweep versus copying garbage collectors
379and their complexity.</a>
380</p><p>
381<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/conservative.html">Pros and cons of conservative garbage collectors,
382in comparison to other collectors.
383</a>
384</p><p>
385<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/issues.html">Issues related to garbage collection vs.
386manual memory management in C/C++.</a>
387</p><p>
388<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/example.html">An example of a case in which garbage collection
389results in a much faster implementation as a result of reduced
390synchronization.</a>
391</p><p>
392<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/nonmoving">Slide set discussing performance of nonmoving
393garbage collectors.</a>
394</p><p>
395<a href="http://www.hpl.hp.com/personal/Hans_Boehm/popl03/web">
396Slide set discussing <i>Destructors, Finalizers, and Synchronization</i>
397(POPL 2003).</a>
398</p><p>
399<a href="http://portal.acm.org/citation.cfm?doid=604131.604153">
400Paper corresponding to above slide set.</a>
401(<a href="http://www.hpl.hp.com/techreports/2002/HPL-2002-335.html">
402Technical Report version</a>.)
403</p><p>
404<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_bench.html">A Java/Scheme/C/C++ garbage collection benchmark.</a>
405</p><p>
406<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/myths.ps">Slides for talk on memory allocation myths.</a>
407</p><p>
408<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/gctalk.ps">Slides for OOPSLA 98 garbage collection talk.</a>
409</p><p>
410<a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/papers">Related papers.</a>
411</p><h1><a name="contacts">Contacts and Mailing List</a><a></a></h1>
412<a>We have recently set up two mailing list for collector announcements
413and discussions:
414</a><ul>
415<li><a href="mailto:gc-announce@linux.hpl.hp.com">gc-announce@linux.hpl.hp.com</a>
416is used for announcements of new versions.  Postings are restricted.
417We expect this to always remain a very low volume list.
418</li><li><a href="mailto:gc@linux.hpl.hp.com">gc@linux.hpl.hp.com</a> is used for
419discussions, bug reports, and the like.  Subscribers may post.
420On-topic posts by nonsubscribers will usually also be accepted, but
421it may take some time to review them.
422</li></ul>
423To subscribe to these lists, send a mail message containing the
424word "subscribe" to
425<a href="mailto:gc-announce-request@linux.hpl.hp.com?subject=subscribe">gc-announce-request@linux.hpl.hp.com</a>
426or to
427<a href="mailto:gc-request@linux.hpl.hp.com?subject=subscribe">gc-request@linux.hpl.hp.com</a>.
428(Please ignore the instructions about web-based subscription.
429The listed web site is behind the HP firewall.)
430<p>
431The archives for these lists appear
432<a href="http://www.hpl.hp.com/hosted/linux/mail-archives">here</a>.
433The gc list archive may also be read at
434<a href="http://dir.gmane.org/gmane.comp.programming.garbage-collection.boehmgc">gmane.org</a>.
435</p><p>
436Some prior discussion of the collector has taken place on the gcc
437java mailing list, whose archives appear
438<a href="http://gcc.gnu.org/ml/java/">here</a>, and also on
439<a href="http://lists.tunes.org/mailman/listinfo/gclist">gclist@iecc.com</a>.
440</p><p>
441Comments and bug reports may also be sent to
442(<a href="mailto:Hans_Boehm@hp.com">Hans.Boehm@hp.com</a>) or
443(<a href="mailto:boehm@acm.org">boehm@acm.org</a>), but the gc
444mailing list is usually preferred.
445 
446</p></body></html>