Gcpp – Experimental deferred and unordered destruction library for C++ | Hacker News Reader

Gcpp – Experimental deferred and unordered destruction library for C++

github.com

70 pointsingve14 comments

For anyone curious, I built a project in C called tgc (https://github.com/orangeduck/tgc) which has some similarities. It's essentially a stand alone version of the Cello Garbage Collector (http://libcello.org/learn/garbage-collection) and provides garbage collection for stack and heap objects allocated via the given functions.

Very nice.

GCC introduced split stack in 4.6 I think. Code that uses this split stack feature would be a problem right ? Anyway to handle those in tgc ?

If I understand it correctly if one rolls ones own spaghetti stack on the heap tgc would still be fine with it. Is that correct ?

Yeah split stacks will be a problem. Essentially `tgc` just scans between the address recorded as the "bottom" and the one recorded as the "top". Both of theses can be manually adjusted if you have some better idea of these locations (such as your own spaghetti stack).

Cool stuff, thanks for the elaboration.

Interesting. Your link says in the portability section

> All it relies on is the assumption that the architecture uses a call stack to implement function frames.

Does this mean it will treat live objects as dead when the only reference is stored in a register?

The registers are flushed to the stack before the mark is performed (using `setjmp`) so unless the behaviour of the platform is particularly odd in this case it shouldn't be an issue.

Very cool. I'm not skilled enough in C++ to comment on any of the implementation details, but I have to say this kind of approach is really neat - sort of an OO-ish encapsulation of memory regions with controllable granularity, with a logical representation of regions as groups of object instances.

This seems to more or less do what Qt's deleteLater()[1] does.

[1] http://doc.qt.io/qt-5/qobject.html#deleteLater

Not really, deleteLater() will simply delete a QObject at the end of the event loop - and since QObjects have an integrated for of unique_ptr, it will delete its whole object graph with it. deferred_ptr is more of a memory region together with a form of integrated GC - it will collect unused object (even if they're part of object cycles) and destroy them when you run collect(). With QObject, you need to call deleteLater() to get rid of each object, and the "later" part only guarantees you that you won't have crashes if the object is still involved in slot calls. With deferred_ptr, you only call collect() on the deferred_heap when it suits you, and it will take care of deleting unused objects.

It doesn't seem so to me.

AFAIK deleteLater and autorelease pools are a way of postponing cleanup until sometime after execution returns to the message loop.

That's not useable for implementing something like a graph class.

Don't know about deleteLater, but autorelease is simply scoped to the enclosing autorelease pool.

    @autorelease {
         [NSMutableArray array];
    }
    --->  the array disappears here

More precisely, the array gets an additional release at that point, so if someone else has retained it, it will stick around. The part about the message-loop is also true: by default, the AppKit creates a pool when it runs the message loop

    -messageLoop
    {
         @autorelease {
             handle one iteration of the loop
         }

    }

So that's the default behaviour you get if you don't do anything else, but you can go as fine in terms of granularity as you want (and the overhead of doing that is pretty minimal and has gotten less with time).

> That's not useable for implementing something like a graph class.

How about Qt's management of QObjects through QObject's parent/child relationship?[1]

[1] http://doc.qt.io/qt-4.8/objecttrees.html

That's perfect for trees :)

That's been in Cocoa as "autorelease" since 1994. Comes free with memory pools too.

Reply on news.ycombinator.com