Re: broken GC

[Miroslav Silovic]

Rob Browning <address@hidden> writes:

> Also, If the maintenance overhead wasn't too high, I'm actually
> fairly intrigued by the idea of a tool that could parse C (basically
> a full C frontend) and generate modified code for the precise GC.
> Such a C mangler might also allow us to do some even more clever
> things with documentation etc.

It's definitely doable. Just make all SCM variables behave like C++
smart pointers (this doesn't have to be smarter than a C++ compiler
from the early 80s). Paul Wilson's GC does this for C++, in fact.

However, I'm still not sure that it's a good idea. For one, precise
marking has a performance impact - you have to add extra magic each
time a SCM variable appears in use. And the other problem, while
working on SART, I /never/ ran into conservativism problems. Mind,
it's an application with 70 entries in C backtraces, with 50-100MB
heap use, running for hours. Also, I worked on TOM, which also has
stack-conservative GC, and I also never ran into problems. I believe
it's a good idea to stick with stack-conservative (remember, it's not
nearly as potentially leaky as the fully conservative GC), and
document the antipatterns that arise from this (such as: don't cons
infinite lists hoping they'll get reclaimed when their head gets
unhooked). However, I wonder if this also makes the use of delay/force
for infinite lists inappropriate.



-- 
How to eff the ineffable?