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 -
So where did the cost come in, compared to other reference-based languages? I think that looking into C++/CLI might also be interesting.
1 reply 0 retweets 0 likes
When reading a garbage collector managed pointer from an object in a thread, it needs to be sanitized through a hazard pointer or similar synchronization mechanism. This is expensive, and needed for every pointer copy and operator->.
-
-
Replying to @TimSweeneyEpic @tmr232 and
For a given number of threads and as given collection strategy one can prove the upper bound of hazard pointers needed. This can greatly simplify and speed up the hazard pointer implementation in C++
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
-
Show additional replies, including those that may contain offensive content
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.