From ... Path: supernews.google.com!sn-xit-02!supernews.com!wn4feed!worldnet.att.net!128.230.129.106!news.maxwell.syr.edu!uio.no!Norway.EU.net!127.0.0.1!nobody From: Erik Naggum Newsgroups: comp.lang.lisp Subject: Re: Allocating on the stack and *only* on the stack Date: 12 Dec 2000 16:25:35 +0000 Organization: Naggum Software; vox: +47 800 35477; gsm: +47 93 256 360; fax: +47 93 270 868; http://naggum.no; http://naggum.net Lines: 57 Message-ID: <3185627135217752@naggum.net> References: <3185549145249958@naggum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: oslo-nntp.eunet.no 976641422 12783 195.0.192.66 (12 Dec 2000 17:17:02 GMT) X-Complaints-To: newsmaster@eunet.no NNTP-Posting-Date: 12 Dec 2000 17:17:02 GMT mail-copies-to: never User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 Xref: supernews.google.com comp.lang.lisp:5110 * Tim Bradshaw | Think of locks or | resources on a remote machine, -- you *really* don't want to leave it | up to the GC to free that kind of thing. I think it is important to realize that GC doesn't _free_ memory or objects. A transitive, active verb here implies something that exists and that something is done to it. Not so. Unreferenced memory does not exist as far as (access to) objects is concerned. The reason it is not usable for new allocations is that even the allocator doesn't know it exists. GC makes such unreferenced memory usable, again, but at this point, we have an essentially uninitialized resource that cannot possibly keep track of what it was last used for. Let's call this _abandoned_ objects and memory. This is in sharp contrast to "freeing" an object, an active operation on an object that still exists qua object. When the free function puts a chunk of bytes back on the free list used by malloc, the memory never _ceases_ to be referenced. It is in fact an _error_ for memory to be abandoned in such a system! (It's 3:30 AM. Do you know where your memory is? My God, it must be hard to live in the C++ mindset, parenting _memory_ as if it were a scarce resource. Sheesh!) I supposed that if you think only in terms of referenced memory and that memory always has a structure, it will be very ahrd to switch to think in terms of unreferenced memory and allowing yourself to let go of memory, since that used to be a source of serious problems and outright pain and suffering during development. If you aren't aware of what hurts, you're likely to fear something else that appears to coincide with it. (Such as people who can't be bothered to figure out the difference between posting to comp.lang.lisp and being stupid.) | And Lisp people *also* confuse it with storage management and since GC | does largely solve that problem assume that these other problems must | be solved too. Let's find a way to help Lisp people overcome that confusion, since GC doesn't solve any other problem than how to reclaim abandoned memory. If something else happens at GC time, I think it needs to be spelled out that there is a (very significant) convenience factor in doing it at that time, not an intrinsic relationship between the reclamation of abandoned memory and the more complex ways through which objects may be discovered to have been abandoned after all the next time around. Example: You don't have to reclaim abandoned memory to find that some object has no other references than that from the finalization list, it's just massively more efficient to mark the old objects you copy in a copying garbage collector so you can walk over the list of objects to finalize and see if anyone of them are still unmarked, at which point you call the finalization code associated with those objects. #:Erik -- "When you are having a bad day and it seems like everybody is trying to piss you off, remember that it takes 42 muscles to produce a frown, but only 4 muscles to work the trigger of a good sniper rifle." -- Unknown