kazinator on Conservative GC can be faster than precise GC

Comment on Conservative GC can be faster than precise GC

Conservative GC is quite vicious against the use of lazy lists:

You have code like this:

  function(make_infinite_lazy_list());

where function walks down the list:

  fun function(list)
  {
     while (list) {  // nil is false
        ...
        list = cdr(list);
     }
  }

problem is, the parent stack frame contains a spurious copy of the original return value from make_infinite_lazy_list, and so as function marches down the list, the discard prefix of the list is not becoming garbage, as expected.

This is the showstopper for conservative GC. Not the bogeyman of a stray machine integer suddenly looking exactly like a heap pointer.

Stick a conservative scanner under C, make yourself some lazy lists, and this problem will easily reproduce!

celeritascelery 2y

Wouldn’t a stack map have that value as well?

kazinator 2y

If the compiler puts out a stack map that is conservative, then the GC scan will be effectively conservative. The compiler has to compensate for that somehow. If a temporary location is in the stackmap, such that the value in it is a dead value before a function call, the compiler has to insert an instruction to null out that temporary location.

Rusky 2y

And the same can of course be done under conservative GC...

kazinator 2y

But it won't, because people implement conservative GCs when they are not in control of all the pieces, like the compilers used for some parts of their run-time.

Rusky 2y

The point of the post is that conservative GC can be useful for reasons other than that simple lack of control.

Comments