2 ms·
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
by kazinator 2y ago
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 agoWouldn’t a stack map have that value as well?
- kazinator 2y agoIf 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 agoAnd the same can of course be done under conservative GC...
- kazinator 2y agoBut 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 agoThe point of the post is that conservative GC can be useful for reasons other than that simple lack of control.