Re: Bitwise sweeping

Hillel Kolodner <[email protected]> Mon, 10 Jan 2011 14:16:10 +0200
Newsgroups gmane.comp.programming.garbage-collection.general
Message-ID <OFF264E6D8.BDBB3D9F-ONC2257814.0042FCD4-C2257814.00436646@il.ibm.com>
Hi Jon,

For previous work on bitwise sweep, see, for example,

Robert T. Dimpsey,=A0Rajiv Arora, Kean Kuiper: Java server performance:=
 A
case study of building efficient, scalable Jvms.=A0IBM Systems Journal =
39(1):
151- (2000).

Regards,
Hillel



From:	"Jon Harrop" <[email protected]>
To:	<[email protected]>
Date:	01/10/2011 02:31 AM
Subject:	[gclist] Bitwise sweeping
Sent by:	[email protected]



I just came up with an interesting idea that might be new...

A region based collector. Regions are aligned on region-sized boundarie=
s so
a pointer to any block within a region can be used to obtain a pointer =
to
the region by zeroing out the low bits. The first cache line in the reg=
ion
stores 512 allocated bits (=3D 1 cache line) that indicate which of the=
 512
blocks in the remainder of the region have been allocated. The second c=
ache
line contains a similar bitvector for mark bits that are zero if the va=
lue
in the block is unreachable and marked as one by the mark phase of the =
GC
if
the value is found to be reachable. Sweeping a region is then simply a =
case
of reading the two bitvectors, computing the bitwise AND and storing th=
e
result back to the first bitvector.

I have implemented a prototype using this technique and it is sweeping =
at a
rate of 40GB of heap objects per second, which is 700x faster than the
sweep
phase of my previous mark-sweep collector. The performance of the whole=

program has improved so much that it has gone from being 20x slower tha=
n
OCaml (which uses a two-generation GC) to just 2-10% slower than OCaml.=

Moreover, the implementation is remarkably simple.

I also allocate using bit-tricks by searching for the first non-255 byt=
e in
the allocated bitvector and using a 255-element lookup table to find th=
e
first zero bit in it. I also remember the last byte in order to restart=
 the
search from there rather than the beginning of the bitvector. This is f=
ast
enough to perform an allocation every 53ns in my benchmark (a purely
functional list-based n-queens solver).

I have read many research papers on garbage collectors over the years b=
ut I
cannot recall any that use bit-tricks like this to accelerate GC phases=

like
sweeping. The Immix paper is the obvious precursor but they allow more
ad-hoc allocations that span lines and so forth, burdening allocation a=
nd
sweeping with significantly more work.

Does anyone know if this is a new idea or what the closest prior art is=
?

There are other obvious advantages in terms of parallelism and concurre=
ncy
too...

Cheers,
Jon.


=