[Mono-dev] (test) GC: seeing if any use...

[BGB]

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 
tiny now...).

I have also put a copy of the thing on my server:
http://cr88192.dyndns.org:8080/bgbgc1.zip

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 
heap).

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 
fairly well...).


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 
OS-specific file).


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 
well...).

(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 
at least...).


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...

or such...