“Cedar goes farther and does not keep track of which local variables contain pointers; instead, it assumes that they all do. This means that an integer that happens to contain the address of an object which is no longer referenced will keep that object from being freed. Measurements show that less than 1% of the storage is incorrectly retained [45].”
Might this explain/justify the GC bug that 32-bit Go once had[1]?
Well, conservative GC is known for this kind of problems, but the overhead is supposed to be generally bounded. I'm not sure about pathological cases; Go may have hit one back then. It highly depends on the circumstances. For example, PLT Scheme used to use the (conservative) Boehm GC in the past, and they've since replaced it, but I don't recall any such problem while they were using it (aside from the somewhat larger but bounded memory usage).
Might this explain/justify the GC bug that 32-bit Go once had[1]?
[1] https://groups.google.com/forum/m/#!topic/golang-nuts/qxlxu5...