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
In my experience people who use garbage collectors spend more time managing resources than people who don't, it's a solution looking for a problem and with tech like arc and raii it's even more redundant
2 replies 0 retweets 4 likes -
Replying to @1stCLord @sombrero_kid
That’s a controversial but plausible statement in mainstream programming practice (despite Unreal and Unity history). It definitely doesn’t hold in the case of code based largely on immutable data structures and shallow copying as in a functional language.
2 replies 0 retweets 1 like -
Replying to @TimSweeneyEpic @sombrero_kid
In this later case (the context of my weekend experiment), the question of “is anybody referencing this data structure” isn’t manageable either locally or globally, so garbage collection is the only possible memory management strategy.
2 replies 0 retweets 3 likes -
Replying to @TimSweeneyEpic
I'm not sure i see why vanilla reference counting can't be used, is it the synchronisation cost?
1 reply 0 retweets 1 like -
ARC on Mac has a very high overhead unless a lot of manual tweaking is applied (which basically kills all advantages of ARC). for such code (with tons of refcounted refs) a GC is most likely faster and with less hassle
2 replies 1 retweet 2 likes -
Replying to @FlohOfWoe @sombrero_kid
That’s exactly what I found with reference counting. Those atomic increments and decrements cost as much as 60 ordinary instructions, and 1000 when highly contended.
2 replies 0 retweets 8 likes -
Would it be reasonable to have per-thread counts to avoid atomics?
1 reply 0 retweets 0 likes -
You can give each object an index, and maintain indexed reference counts per thread, so 4B * 32 threads = 128B per object overhead that must be scanned every GC cycle. That’s a lot of overhead though.
1 reply 0 retweets 0 likes
So you get to “card tables” as an alternative, storing a global table of 1B per region of memory (say 8B to 4KB) indicating that it contains pointers to be scanned. Then the GC memory overhead is bounded to 1/64.
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.