Re: [HACKERS] Its not my fault. Its SEG's FAULT! - Mailing list pgsql-hackers

From dg@illustra.com (David Gould)
Subject Re: [HACKERS] Its not my fault. Its SEG's FAULT!
Date
Msg-id 9804030725.AA12275@hawk.illustra.com
Whole thread Raw
In response to Re: [HACKERS] Its not my fault. Its SEG's FAULT!  (Tom Ivar Helbekkmo <tih@Hamartun.Priv.NO>)
List pgsql-hackers
Tom Ivar Helbekkmo writes:
> dg@illustra.com (David Gould) writes:
>
> > I would like to discuss the idea of replacing the current scheme of
> > explicit memory allocation and and deallocation from separate
> > "MemoryDuration" pools with a conservative garbage collector.
>
> Yes!  This is a great idea!  [scrambles, grinning, to finally get to
> work on porting the Boehm-Weiser collector properly to NetBSD/* 1.3]

This is exactly the kind of thoughtful response I was looking for ;-)

> It seems, from recent discussion, reasonable to assume that this will
> kill a number of bugs, reduce the memory footprint of the backend and
> quite possibly even (judging by the profiling data you quote) give a
> welcome performance boost.  Will you be doing some trial runs with
> Boehm-Weiser simply linked in as a malloc/free replacement?  Is it a
> big project to actually rip out the MemoryDuration allocator's guts to
> get rid of some of that overhead?

Not too big, just redefine palloc and make the Context calls into no-ops.
A bit more trouble to track down all the 'malloc()' calls that shouldn't
have ever been there (but there are quite a few).

> Of course, this one [he said, grinning]:
>
> (define (do-thing)
>   (with-handler my-handler
>                 (do-the-wild-thing)))

Sure, but right now we have some few hundred thousand lines of C...

> > Unsupported assertions to the effect "GC is too slow ... only works
> > with lisp ..." etc are ok too, but will be eligible to win valuable
> > prizes.
>
> ...like a guide to documents on the net debunking these and other
> favorite misconceptions about garbage collection?  You're hardly

I had meant to say "not be eligible" but I like your idea better. Both
urls I posted have a bunch of very fine links to a lot of really good
information.

> likely to get too many of those assertions, though: by now, I would
> assume that it's gotten through to most programmers that the handling
> of memory in a large system can be done more reliably _and_ more
> efficiently by a good garbage collector than by a C programmer.  The

It is surprising, but this simple fact has not yet penetrated into
popular thought. I have seen large organizations full of very bright
people spend hundreds of man years chasing leaks without ever wondering
if there might be an alternative.

For some reason people cling to the belief that if they were just careful
enough and only let really good programmers touch the code and carried
a lucky rabbits foot that somehow they could write leak free software.

All this in the face of the observation that no-one ever actually _writes_
leak free software. Personally, I don't know anyone who can write leak
free software of any size, certainly not in a finite time.

-dg
>
David Gould            dg@illustra.com           510.628.3783 or 510.305.9468
Informix Software  (No, really)         300 Lakeside Drive  Oakland, CA 94612
"A week of coding can sometimes save an hour of thought."

pgsql-hackers by date:

Previous
From: "Maurice Gittens"
Date:
Subject: Re: [HACKERS] inherited sequences and primary keys
Next
From: dg@illustra.com (David Gould)
Date:
Subject: Re: [HACKERS] inherited sequences and primary keys