It's a non-moving collector. It might be high performance by the standards of C++ garbage collectors, but I doubt its performance could be anywhere near what a decent JVM can manage, especially in the absence of finalizers/destructors. As Ron Pressler ( pron here on HN) has been emphasising recently, [0] the 'sweep' phase of a moving garbage collector is unaffected by the size or number of dead objects in the heap (a…
I think it's a good thing to separate requirements/problems/etc. 1: Java has an horrendeous amount of unnecessary garbage due to their erasing generic design (until Valhalla ever arrives), there was some old blog post that chronicled the creation of Dictionary for C#'s System.Collections.Generic (as opposed to the initial Java-like System.Collections) and how it reduced garbage-load by an magnitude. Java chose compat…
It doesn't. I've been building one as a plain header-only library (SGCL, https://github.com/pebal/sgcl - my project): the heap is traced precisely through per-type pointer maps the collector builds at runtime by elimination (a word ever seen holding a non-heap value is data, for good), marking and sweeping run concurrently with the mutators and in parallel over helper threads, cycles are generational, and nothing is ever moved. What it can't do without the compiler is the stacks, which it scans conservatively, like Go before 1.4.
On the "abstract model" point: you're right that it isn't 100% faithful either. The collector reads words of objects while other threads write them, relies on word-sized stores being what every real platform makes them, and reads stacks it does not own. The rules the program has to keep are few (a tracked pointer lives on a stack or in a managed object, never shares storage with data, destructors don't touch peers) and debug builds check them, but it is engineering on top of the platforms, not the standard.