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
-
Now I see why the best relocating collectors, like Microsoft's for .NET, "stop the world" at critical times. That's not workable in general C++ code though, and won't scale to many-core. Conclusion: A non-relocating concurrent garbage collector will be optimal.
11 replies 10 retweets 65 likesShow this thread -
Replying to @TimSweeneyEpic
What's the usecase for relocation? Fragmentation? Large allocs with serial access?
1 reply 0 retweets 0 likes
Replying to @_vkaku
Relocation ensures less fragmentation and higher cache and TLB locality, and can also enable lower-cost freeing than random access memory managers. Yet any purely concurrent scheme requires some pinning, so the benefits of relocation are reduced.
5:58 AM - 16 Jul 2018
0 replies
0 retweets
4 likes
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.