Garbage collection of binaries

[Joachim Durchholz]

Erik Stenman wrote:
> ERTS currently uses a generational *copying* GC,

Ah, I overlooked that.

> hence storing the binaries directly on the heap without rewriting the
> GC would mean that the binary would be copied at each major GC.

Hmm... good reasons, but that's the wrong place to address the problem,
I think.

Copying collectors are designed for minimizing fragmentation. In other
words, the memory area that stores binaries will be fragmented.
Particularly if the binaries come and go quite often, and have slightly
different sizes (which I'd expect for large data like binaries).

In other words: the distinction whether to copy some data or not should
be based on the size of that data, not on its status as a binary. And if
copying indeed is a problem (it shouldn't be, but theory and practice
differ more in practice than theory would admit *g*), the solution
should be in the GC mechanism. Not in a tacked-on reference counting
mechanism that doesn't even interoperate well, and that might expand the
footprint beyond reasons.
Actually, this is the kind of behaviour that can break systems, and from
the reports on this list, I conclude that this has already happened. Not
the kind of behaviour that I would have expected from a safety-minded
language like Erlang :-((

I'm frustrated. From the outside, you always get promises. From the
inside, things are not so rosy.
*sigh* still questing for a rock-solid, really reliable language...

... and all of this is a "wonderful" example that getting garbage
collection right is *hard*. Don't try this at home and all.

Regards,
Jo