Smieciuch++ 0.6.3 review

Smieciuch library is a precise (in case of C++) or nearly precise (in case of plain C) tracing garbage collector. Tracing means th

License: GPL (GNU General Public License) File size: 0K Developer: Sebastian Kaliszewski

0

Smieciuch library is a precise (in case of C++) or nearly precise (in case of plain C) tracing garbage collector.

Tracing means that GC scans memory for active pointers and traces all paths (consisting of possibly multiple pointer indirections) from so called memory roots (static global data and execution stack(s)) to any reachable allocated heap block. If there are not paths from memory roots into some block then such block is recognised as dead (unreachable) so it might be freed.

Being precise means that it is impossible to mess managed pointer (aka managed reference) with any other kind of program data. Oposite term is conservative - in such case collector (aka memory manager) does not know for sure if particular data is managed pointer or not and thus anything what might be pointer (that usually means anything whichs value might be interpreted as pointer into one of allocated heap areas) is treated as a live pointer to some memory area and thus protects that (allocated) area from being freed. So conservative garbage collector might (an in real life often does) recognise some dead memory objects as still alive (thus wasting memory).

In real life such problems get more and more pronounced when percentage of total address space used by application increases. And those are often the cases where memory usage is an important problem.

C++ Smieciuch is precise so there are no such issues, but more explanations are needed for C variant's near precission...

C Smieciuch is fully precise for everything but stack located managed references. If there is right (or rather wrong) set of conditions some non managed pointer data could for the eyes of collector impersonate some managed pointer used by some earlier invoked procedure. There must be three bads in line:

GC didn't notice that one procedure is finished and another one is now using stack area previusly used by finished one, and miss the fact that nonstatic variables used by previous procedure are now dead;
Place on stack previously (during finished procedure execution) occupied by managed pointer is now (at least partly) occupied by some other type of variable;
Value stored into that new variable causes that place on stack to form a valid address to one of allocated heap objects.

As one can see this problem is well localised. I'm thinking about techniques to reduce it even further, but I have no idea how to get rid of it completely.

Mind you, this is only the case of C code, as in C++ managed pointers are encapsulated by apropriate smart pointer classes and destructors take care of informing GC that particular managed pointer is no longer live.

What's New in This Release:
This release fixes a problem with too much consumption of stack, which occurred as garbage collector scanned deeply nested recursive structures like long linked lists, leading on some platforms to stack overflow.
It compiles cleanly on GCC 4.0.
It is about 10% faster than boost::shared_ptr (as measured in heavy pointer use benchmark).