Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!usc!snorkelwacker.mit.edu!shelby!agate!ucbvax!ucsfcgl!babar.mmwb.ucsf.edu!srp From: srp@babar.mmwb.ucsf.edu (Scott R. Presnell) Newsgroups: comp.sys.sgi Subject: Re: Pointer validation code Message-ID: Date: 6 Feb 91 15:53:56 GMT References: <9102041731.aa11984@WOLF.BRL.MIL> <84166@sgi.sgi.com> Sender: daemon@cgl.ucsf.edu Lines: 50 donl@glass.esd.sgi.com (donl mathis) writes: >In article <9102041731.aa11984@WOLF.BRL.MIL>, mike@BRL.MIL (Mike Muuss) writes: >> I handle memory corruption and pointer mis-handling in a rather >> different manner. I have "wrapper" subroutines called >I have a similar package that accomplish much the same thing, but in a >somewhat more formal environment. My model for memory use was that a [...] With all this talk of pointer validation, wrappers for alloc etc. I thought I'd ask if anyone had been using the C garbage collection scheme posted to comp.sources.unix about a year and a half ago? Having learned Lisp before C I thought garbage collection was a pretty cool idea... I ran the test and tried it out a couple of times on my own small programs without any problems, but I haven't used it in a "production" tool yet. Anyone using it out there? This is the header to the post: = =This is intended to be a general purpose, garbage collecting storage =allocator. The algorithms used are described in: =Boehm, H., and M. Weiser, ="Garbage Collection in an Uncooperative Environment", =Software Practice & Experience, September 1988, pp. 807-820. = =Many of the ideas underlying the collector have previously been explored =by others. (We discovered recently that Doug McIlroy wrote a more or less =similar collector that is part of version 8 UNIX (tm).) However none of =this work appears to have been widely disseminated. = =The tools for detecting storage leaks described in the above paper are not =included here. There is some hope that they might be released by Xerox in =the future. = =Since the collector does not require pointers to be tagged, it does not =attempt to insure that all inaccessible storage is reclaimed. However, =in our experience, it is typically more successful at reclaiming unused =memory than most C programs using explicit deallocation. = Just curious - Scott Presnell (srp@cgl.ucsf.edu) -- Scott Presnell +1 (415) 476-9890 Pharm. Chem., S-926 Internet: srp@cgl.ucsf.edu University of California UUCP: ...ucbvax!ucsfcgl!srp San Francisco, CA. 94143-0446 Bitnet: srp@ucsfcgl.bitnet