This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
> From: Per Bothner <per@xxxxxxxxxxx> > Tom Lord wrote: > > (b) it turns out that conservative GC is a sham in the sense that if > > you use it without a deep understanding of permissable C optimizations > > and eternal vigilance about what they might effect -- you're going to > > lose by writing subtly incorrect code. > Nah. Theoretically possible, but I've never heard of it actually > effecting real code. To the extent that you consider Guile / Systas "real code" (and that's debatable, I admit :-), now you have. Really: I've seen it happen in practice. Code gets the flakies (core dumps "sometimes"). Debugger shows that it's because the GC is confused and there's little hope of catching it when it happens unless you can reproduce the error reliably. On a hunch, you review some of the functions that you think your program is exercising to an unusual degree and, sure enough -- find a conservative GC bug. Fix it and the flakies go away. > GCJ uses the Boehm conservative collector. Using a precise > collector with code generated by an optimizing compiler is > difficult. Some _uses_ of conservative GC are more resistent to these kinds of bugs than others and gcj may very well be one of them. But yes, I'd agree that "precise collector vs. optimizing compiler" is hard too -- I'd only caution that "ease of use" is never an accurate argument for conservative over precise and that retrofitting conservative collection to a program that formally used other memory management techniques pays off only probabilistically and with failure rates much more significant than cosmic rays. I think Pika-style does a good job of containing the difficulties for FFI-users for both conservative and precise collectors. It pushes the difficulties off onto the FFI-implementor. (JNI/Minor-style does too.) -t