From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Han-Wen Newsgroups: gmane.lisp.guile.devel Subject: Re: GUILE GC -- Write barrier for vectors Date: Wed, 17 Jul 2002 23:53:54 +0200 Sender: guile-devel-admin@gnu.org Message-ID: <15669.59250.42319.158681@blauw.xs4all.nl> References: <15667.21636.174313.24740@blauw.xs4all.nl> Reply-To: hanwen@cs.uu.nl NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1026942767 23306 127.0.0.1 (17 Jul 2002 21:52:47 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 17 Jul 2002 21:52:47 +0000 (UTC) Cc: guile-devel@gnu.org, jantien@xs4all.nl Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17Uwj0-00063l-00 for ; Wed, 17 Jul 2002 23:52:46 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17Uwij-0002QJ-00; Wed, 17 Jul 2002 17:52:29 -0400 Original-Received: from smtpzilla3.xs4all.nl ([194.109.127.139]) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17UwhC-0002OL-00 for ; Wed, 17 Jul 2002 17:50:54 -0400 Original-Received: from blauw.xs4all.nl (blauw.xs4all.nl [213.84.26.127]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g6HLorhr089101; Wed, 17 Jul 2002 23:50:53 +0200 (CEST) Original-To: Dirk Herrmann In-Reply-To: X-Mailer: VM 7.05 under Emacs 21.2.1 Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:816 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:816 dirk@sallust.ida.ing.tu-bs.de writes: > > I'm reading the patent (gosh, what verbosity) -- but interestingly, > > the claim is only made for not copying entire pages (cards in Scheme > > terms), that are marked conservatively. If you one uses a second set > > of mark bits, you could leave alone exactly those objects that are > > marked conservatively (iso. the whole page). The price is that you > > have another mark-bit vector (1.5 % memory overhead), that the free > > space in the conservatively marked pages is fragmented, and that there > > is more overhead (checking the marked-conservatively-bit) during the > > copy phase. > > Interesting. But: isn't the conservatively marked page fragmented > anyway? At some time a few objects in a conservatively marked page will > be collected. That is, wouldn't we need to keep track of conservatively > marked cells (in contrast to pages) anyway? Yes, but the point is that you can not move marked cells in a conservatively marked page. Somewhere along the line (if you do copying GC), you have to say if (conservatively_marked (cell)) ; else copy_cell_to_new_location () for bartlett conservatively_marked() equals "this page contains a conservatively_marked object". -- Han-Wen Nienhuys | hanwen@cs.uu.nl | http://www.cs.uu.nl/~hanwen _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel