[Mono-dev] (test) GC: seeing if any use...
cr88192 at hotmail.com
Mon Jan 12 01:53:52 EST 2009
well, I have gone and split apart my prior garbage collector library into
several parts, and have moved most of the stuff that was formerly there into
a different library (with just the GC and a few other things, my library is
I have also put a copy of the thing on my server:
if anyone has trouble and wants to look at it, ask and I will email it, I
just was a bit unsure about trying to send it as an attachment...
at present, it does not have precise GC, but I will probably get around to
adding this if anyone is interested.
I don't know if it, as is, will be of any use to the project, but I just
figured I would make it available just in case it might be.
the API is partly specified in the 'docs' subdir, along with the idea for
the API for the precise GC I might add...
probably about the only real advantage it has is that the per-object
overhead is fairly low:
smaller objects are allocated in 16 byte cells, with the first cell
containing a header. the header will currently take 8 bytes on x86, and 16
on x86-64, but I could get it down to 4 on both (and allow a 4, 8, or 16
byte alignment, and allowing objects <=12 bytes to only take 16 bytes on
the cons allocator seems to be left, where a cons is a small object
consisting of 2 pointers (typically called 'car' and 'cdr'), however all the
frontend code for using conses is gone. on x86, each cons takes 8 bytes and
does not have a header (since it is 2 ptrs, it takes 16 bytes on x86-64).
larger objects are currently allocated via malloc (except executable
objects, which always use cells).
but, yeah, I use cells for small objects as my code has typically allocated
lots of small objects (especially cons cells), and a small performance
overhead seemed reasonable (very rarely has raw allocation or free
performance been that major of a factor though, and so usually it works
it does work in multithreaded code, but due to technical issues this is not
a good area at present (never got around to implementing a proper write
barrier, but it does provided a software write barrier FWIW...).
as-is, it only works on Windows and Linux, but this had been good enough for
my uses in the past (if needed, the OS-dependent bits could be moved into an
as another cost, it is presently only mark/sweep (although, it is concurrent
mark/sweep at least).
if/when the precise allocator is added, I could either use mark/sweep or a
generational collector (there is always lots of hype for generational
collectors, but I have not seen much what the big deal is myself, but oh
(I have my doubts that it will be of an acceptable level of performance or
reliability for production code... yeah... but it is good enough for my uses
but, oh well, just checking here, I don't expect much interest...
hell, if even some of the algos or the API design were of interest, that
would be good enough...
More information about the Mono-devel-list