Re: Bitwise mark-region collection

Walter Schreppers <[email protected]> Tue, 11 Jan 2011 15:25:10 +0100
Newsgroups gmane.comp.programming.garbage-collection.general
Message-ID <[email protected]>
I need to see some code before discussing this topic. Without some actual
code to look at, I can't join the discussion ;).


On Tue, Jan 11, 2011 at 11:39 AM, Jon Harrop <[email protected]>wrote:

> Hans Boehm wrote:
> > We reconstruct free-lists at GC time, and they're built in address order.
>
> I see. There are some parallels between your mark bit array and my bitwise
> approach, advantages that my previous solution using free lists lacked.
>
> Incidentally, this gives me another idea: I should optimize the mark phase
> for marking sequences of blocks that reference their (unmarked) neighbours,
> setting all of the bits in the bitvector simultaneously. Then there wouldn't
> be any individual bitwise operations on the hot path...
>
> > Sweeping is relatively cheap for us...
>
> What does your performance profile look like when lots of small values are
> being recycled? What proportion of time is spent in marking and in sweeping?
>
> > > 2. There is no way to exploit the sparsity of deallocations, which
> > > often occur in contiguous runs when locality is preserved by using an
> > > allocator that hands out free blocks in order.
> >
> > If the GC is responsible for most deallocations, then we preserve
> locality,
> > and we sometimes do benefit from large empty blocks.
>
> What happens when you encounter a run of several consecutive unmarked
> allocated blocks? Presumably you append each one in turn to the end of the
> free list?
>
> > > 3. The size of the free list is considerable when your allocated blocks
> > > are as fine-grained as mine (e.g. 50% overhead when allocating 8-byte
> > > blocks).
> >
> > We link the blocks themselves through the first word, so there is no
> space
> > overhead.
>
> I was referring to your link pointers as overhead because they don't exist
> using this bitwise technique: the space requirements are a single bit per
> block rather than 1 word per block.
>
> Cheers,
> Jon.
>
>
> Trayport Limited
> Registered in England at 4th Floor Rose Court, 2 Southwark Bridge Road,
> London SE1 9HS
> Company registration no.2769279.
>



-- 
Schreppers I.T.
Phone: +32.486.11.88.36
Fax: +32.3.239.68.24
Mail: [email protected]