Re: [HACKERS] Its not my fault. Its SEG's FAULT!
От | dg@illustra.com (David Gould) |
---|---|
Тема | Re: [HACKERS] Its not my fault. Its SEG's FAULT! |
Дата | |
Msg-id | 9804030725.AA12275@hawk.illustra.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Its not my fault. Its SEG's FAULT! (Tom Ivar Helbekkmo <tih@Hamartun.Priv.NO>) |
Список | 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 по дате отправления: