From owner-freebsd-ports Thu Nov 14 02:35:14 1996 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA29358 for ports-outgoing; Thu, 14 Nov 1996 02:35:14 -0800 (PST) Received: from heraclitus.cs.monash.edu.au (heraclitus.cs.monash.edu.au [130.194.64.241]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA29342 for ; Thu, 14 Nov 1996 02:35:03 -0800 (PST) Received: (from mmcg@localhost) by heraclitus.cs.monash.edu.au (8.7.5/8.7.3) id VAA23137; Thu, 14 Nov 1996 21:34:59 +1100 (EST) From: Mike McGaughey Message-Id: <199611141034.VAA23137@heraclitus.cs.monash.edu.au> Subject: Garbage collection package? To: ports@freebsd.org Date: Thu, 14 Nov 1996 21:34:59 +1100 (EST) Cc: mmcg@heraclitus.cs.monash.edu.au (Mike McGaughey) In-Reply-To: <8178.847925848@time.cdrom.com> from "Jordan K. Hubbard" at "Nov 13, 96 02:57:28 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ports@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Is there any interest in adding the Boehm/Weisner conservative garbage collection package as a standard package? It's already been ported to FreeBSD (and dozens of other systems), compiles out of the box, works like a charm. It supports C++, albiet not quite as well as C (I use it for both). It can be used as a (brilliant!) leak detection package. It also has a decent debugging malloc (only for C, not C++). All it needs is a better man page. Skip the rest of this message if you already know what conservative GC is - I'm about to get a bit evangelical. I reckon that every decent operating system should come with a standard GC & leak library :) If you don't know what I'm on about: A garbage collector is a system that finds all allocated memory that is now unreachable through pointers held by a program, and frees it automatically (it's typically invoked by malloc when it can't find space to allocate). Garbage collection can coexist with the use of `free', and hence can be used to deal with those few `difficult' cyclic structures that you can't be bothered writing good memory management for. Obviously, if you *do* want to free everything, such a system is also ideal for working out when and where you are leaking memory. It's saved me hundreds of hours of development time over the years. The Boehm package is a `conservative' garbage collector, which, for our purposes, means it works with C and C++ (which is actually pretty hard to get right, given disguised pointers, unions, etc). It's impressive - C programs work with it without change. I use two libraries, -lgc and -lleak, which contain replacements for malloc/free/new/delete/etc, and I simply link against whichever I want (or against neither of them), depending on whether I feel like looking for leaks that day. If you want debugging GC as well, you need to include a header file. Otherwise, it's completely unintrusive. Programs which never free memory, and instead rely exclusively on GC, can run considerably slower and larger; however, GC overhead is minimal if you free all of the `easy' stuff by hand (that's 99% of it), and let the GC clean up the rest (in which case, GC overhead is reduced to a few percent of CPU). I have plenty of production quality software that relies on the Boehm package; also, a couple of my compilers (for languages which generate other sorts of GC'd code) use it when bootstrapping themselves. NB: Licence is `you may use this for any purpose whatsoever', and current version is 4.10 (though there's now a 4.11a). I got mine from ftp://parc.xerox.com/pub/gc/gc4.10.tar.gz. libgc and libleak need to be compiled with -DREDIRECT_MALLOC if you want to get a drop-in malloc replacement. Any interest in including it? Cheers, Mike, just a happy (and impressed) user (and GC researcher :). ps: Once you've tried it, GC is highly addictive :)