After 3 months of coding weekends, my attempt to create a relocating nonblocking garbage collector in C++ has failed. It works in theory, but in practice the read barrier is pervasive and costly, and the threading invariants are incredibly tricky to maintain.
-
Show this thread
-
Replying to @TimSweeneyEpic
There are a few paid versions for Java: is there something about Java semantics that makes it easier to do there ?
1 reply 0 retweets 0 likes -
Replying to @F_Vaggi @TimSweeneyEpic
JVM is implemented in c/c++. So, if it's possible in Java, it should be possible in c
1 reply 0 retweets 1 like -
Memory in Java is managed by JVM. In C and C++ you manage your own memory, working with raw pointers. You have no means of moving pointers around without invalidating variables and code.
2 replies 0 retweets 1 like -
Within c, you can ask system to move the data around and then update the pointers to point to new location. My point is, if something is possible in jvm, that should be possible in c.
1 reply 0 retweets 1 like -
I agree. But the semantic difference is large. JVM can track pointers and know where all the pointers in a running program are. In C you have no way of knowing what's a pointer and what isn't. That said, you *may* be able to handle well-behaved code given compiler support
1 reply 0 retweets 2 likes -
I am almost certain any kind of GC system in C/C++ would be opt in for pointers that are specifically owned by the GC - ala boehm GC
1 reply 0 retweets 0 likes -
My approach is even simpler: GC only occurs on ref<t> smart pointers and only when allocated through forwarding ref<t>(..) ctors. Thus GC is opt-in and orthogonal to explicit lifetime management of other objects.
2 replies 0 retweets 5 likes -
Replying to @TimSweeneyEpic @F_Vaggi and
How do you keep track of roots? Don't you still need to trace through arbitrary C++ structures which may be holding on to `ref<t>`s to determine if they're reachable (and where, once again, you don't know what's a pointer and what isn't)?
1 reply 0 retweets 0 likes -
Replying to @glaebhoerl @F_Vaggi and
I maintain a bitmask of all locations in unmanaged memory that contain ref<t>, set in the ctor and cleared in the dtor. Those bits are used to locate roots (conservatively, given races), plus there’s a dirty-flag per object to indicate recent rootedness.
2 replies 0 retweets 3 likes
These two techniques suffice to take a conservative “snapshot of all liveness relations” at the start of concurrent GC, then mark and sweep in a background thread with no blocking, in regular C++ with no user or OS level hackery.
-
-
Replying to @TimSweeneyEpic @F_Vaggi and
Hmm. Does any actual tracing (pointer chasing) happen? Or is it just a direct test of "out of the N ref<t>s which were pointing to this object/location, are any still alive"?
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.