> From: Per Bothner <xxxxxx@bothner.com>

    > 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