guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GUILE GC -- Write barrier for vectors


From: Dirk Herrmann
Subject: Re: GUILE GC -- Write barrier for vectors
Date: Sat, 20 Jul 2002 01:48:13 +0200 (CEST)

On Wed, 17 Jul 2002, Han-Wen wrote:

> address@hidden 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". 

If I understand things right, then the technique to treat a whole page as
conservatively marked even if only a single one of its cells is actually
conservatively marked is a kind of optimization. Now, the question is,
whether this optimization is useful:  Every page that is marked
conservatively will be kept occupied as a whole, even if all cells except
for the one conservatively marked cell are collected.  That is, the free
space in that page is fragmented anyway.  To re-use the free cells in that
fragmented page would require handling of fragmented pages.

Best regards,
Dirk




reply via email to

[Prev in Thread] Current Thread [Next in Thread]