Re: Switch from SBCL to Erlang backend due to scalability issues(GC).

Russell McManus <russe@xxxxxxxxxxx> writes:

"michael.warnock@xxxxxxxxx" <michael.warnock@xxxxxxxxx> writes:

I could never nail down what type of activity was producing unclaimed
garbage, because I forced each sort of thing to happen in isolation,
and it was always cleaned up, in isolation. The oddest thing to me,
and the reason I ultimately gave up trying to find the problem in my
own code, was that, given an image that had already grown in this way,
I could destroy all my root objects (hashes mostly), run a full gc,
and still be using nearly the same amount of memory as before.

Isn't this the hallmark of "issues" with conservative collection? I
think that the default sbcl collector on i386 is conservative.

Yes, you're right. I found this on

On the x86 SBCL -- like the x86 port of CMUCL -- uses a
conservative GC. This means that it doesn't maintain a strict
separation between tagged and untagged data, instead treating some
untagged data (e.g. raw floating point numbers) as possibly-tagged
data and so not collecting any Lisp objects that they point to.
This has some negative consequences for average time efficiency
(though possibly no worse than the negative consequences of trying
to implement an exact GC on a processor architecture as
register-poor as the X86) and also has potentially unlimited
consequences for worst-case memory efficiency. In practice,
conservative garbage collectors work reasonably well, not getting
anywhere near the worst case. But they can occasionally cause odd
patterns of memory usage.

Does anyone know why CMU-CL and SBCL do that? This snippet only says
that they think a conservative GC is probably not slower than a
precise GC on x86. It doesn't say they think it's faster. That
sounds to me like the reason was not efficiency. What was it then?

Wolfram Fenske

A: Yes.
Q: Are you sure?
A: Because it reverses the logical flow of conversation.
Q: Why is top posting frowned upon?