From ... Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed00.sul.t-online.de!t-online.de!newsfeed.esat.net!nslave.kpnqwest.net!nloc.kpnqwest.net!nmaster.kpnqwest.net!nreader2.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: self-hosting gc References: <87elj5i2rf.fsf@becket.becket.net> <87elj5glx5.fsf@becket.becket.net> <3223987471212925@naggum.net> <3c7fe967$0$234$ed9e5944@reading.news.pipex.net> Mail-Copies-To: never From: Erik Naggum Message-ID: <3224012428193198@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 48 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Mar 2002 23:00:22 GMT X-Complaints-To: newsmaster@KPNQwest.no X-Trace: nreader2.kpnqwest.net 1015023622 193.71.199.50 (Sat, 02 Mar 2002 00:00:22 MET) NNTP-Posting-Date: Sat, 02 Mar 2002 00:00:22 MET Xref: archiver1.google.com comp.lang.lisp:27684 * "Martin Simmons" | Yes, but the two-space model usually assumes equal sized spaces. If | from-space is almost full of live data you won't have much room in the | to-space for data allocated during the copying. I assume that if this technique is used at all, it is used all the time, it is not suddenly used in a system that did not do this previously, but your argument looks like you think someone would suddenly start to do some allocation in the garbage collector of a Common Lisp system that had never done this before. I find this a rather peculiar inability to see the simplest possible ramification of a suggestion: that it be used all the time. So, at least some of the garbage in from-space is the direct result of its collection phase of what is now to-space, right? In other words, there is at least as much space as you allocated last time you collected. Also, what happens in a system that does not allocate during collection? Do they crash and burn if they they have to grow their new-space because it did not release enough space on the last allocation? No? If not, survival tactics of a similar kind _might_ be re-usable in a collector that does allocation, don't you think? In other words, your fake "problem" does not exist. If it should spring up nonetheless, the solution is the same as for a system that does not allocate during collection. Worst case, we start garbage collection some time prior to actually hitting the roof of the available space. Yet none of these very trivial solutions came to mind between starting to write your article and deciding to post it after it was written. How come? | Also, the subset of Lisp available will be constrained to things that can | run safely at any allocation point. E.g. you can't use anything that | alloctates while holding a lock (I'm assuming the is keeping some data | structure consistent). This makes even less sense than your previous, non-existing problem. What other parts of the system inhibits allocation while being locked? Please remember that garbage collection happens at a time when the memory allocation subsystem has the control of the system, so if you had a lock and you never allocated anything before releasing it, you would never trigger a garbage collection in the first place. Do not waste my time by trying to make me think for you. Think and post in that order. please. /// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.