Issues I found at a glance:<p>1. This uses unsigned int for the chunk size, so the allocator will overflow on requests of 4GB or more despite taking a size_t. It seems that this is 32-bit only.<p>2. Even on 32-bit, the num_units calculation will overflow if you request (for example) 0xffffffff bytes of memory instead of returning an error.<p>3. None of this is thread-safe. It needs a global mutex lock.<p>4. EBP cannot be relied upon to yield anything sensible with -fomit-frame-pointer, which is common on 32-bit x86 as it brings the number of GPRs from 6 to 7.
This really reminds me of a project called TinyGC/tgc[0], made by Daniel Holden who is currently a Ubisoft researcher. I have also tried his Cello[1] framework for C99 which also incorporated a garbage collector similar to tgc. Cello is pretty fun to use but the syntax was still limiting.<p>[0]: <a href="https://github.com/orangeduck/tgc" rel="nofollow">https://github.com/orangeduck/tgc</a><p>[1]: <a href="https://github.com/orangeduck/Cello" rel="nofollow">https://github.com/orangeduck/Cello</a>
As another example, here's a simple GC I wrote quite a while ago in Forth: <a href="https://github.com/JohnEarnest/Mako/blob/master/lib/Algorithms/Garbage.fs" rel="nofollow">https://github.com/JohnEarnest/Mako/blob/master/lib/Algorith...</a><p>This one is a precise, copying GC, with a reserved arena for persistent references into garbage-collected objects (in addition to the stacks). Pointers are identified by reserving a high bit in words.
This GC does not probably survive to pointer scrambling. If believe in C I can validly do something like<p><pre><code> int *ptr = ...;
intptr_t iptr = (intptr_t) ptr;
ptr = NULL;
iptr ^= MAGIC;
// do something else
ptr = (int*) (iptr ^ MAGIC);
</code></pre>
At the end of this ptr is again a valid pointer to the same thing it was pointing at the beginning. However, if a GC scan will happen during the "do something else" block, it won't see the actual pointer value and it might free the pointed object.<p>I don't think it is possible to write a GC for C if the program is allowed to do this kind of things, because there is too little structure at runtime. And in any case, this kind of GC is not a GC "for C", as it heavily relies on knowing the compiler internals.<p>EDIT: Re-reading, I didn't mean to be harsh. This is still interesting to read, I am just noting a weakness that is not mentioned in the article. BTW, I know that glibc actually does some pointer scrambling like I said to mitigate some types of attack.
I had a co-worker who was a sysadmin and was writing a GC on his own time. Just for fun. The guy was seriously over qualified but I guess he chose to work with simple stuff for his own sanity.
It's great to see tutorials like this. FWIW, here's a tiny incremental (baker treadmill) collector[0] library I wrote. It was used in the implementation of the Io programming language.<p>[0] <a href="https://github.com/stevedekorte/garbagecollector" rel="nofollow">https://github.com/stevedekorte/garbagecollector</a>
Another great article on the subject:<p><a href="http://journal.stuffwithstuff.com/2013/12/08/babys-first-garbage-collector/" rel="nofollow">http://journal.stuffwithstuff.com/2013/12/08/babys-first-gar...</a>