Garbage collection of binaries

[Bjorn Gustavsson]

Garbage collections of binaries is a tricky issue.

To clarify how binaries are removed: It is done by a combination of
garbage collection and reference counters. Binaries are represented in
each process as small objects on the heap. Those objects are also part
of a linked list (one list per process). After each garbage collection,
the linked list is scanned to which objects were not moved (thus, no longer
referenced). For each unreferenced object, the reference count in the binary
itself is decreased.

As a consequence of the above, if a binary is referenced from the
old generation heap, it cannot be removed until a new major collection
(a.k.a. fullsweep collection) is done. How often a major collection occurs
depends on the application.

If a process is known to have large binaries but small amounts of live
heap data, the process can be started using the spawn_opt/4, passing in the
'{fullsweep_after,0}' option. (See the documentation for spawn_opt/4 for
further details.) That will make every GC a major collection (fullsweep),
cleaning away any binaries that are no longer referenced.

Note that a major collection copies all data that is is still alive; if you
have large amounts of live data on the heap doing a major collection every time
will typically be slower than the default generational GC (which only does a
major collection when there is no more place on the old generation heap).

BTW, when a process aquires a new binary, it gets "penalty points" so that it
will be garbage collected sooner. But a binary that has survived one GC will
not generate further "penalty points".

/Bjorn

Jesper Wilhelmsson <jesperw@REDACTED> writes:




> On Fri, 17 Oct 2003, Joachim Durchholz wrote:
> 
> > Jesper Wilhelmsson wrote:
> > > Binaries are referenced counted and are removed when their conter reach
> > > zero.
> >
> > This gives me another approach: when you're done with a binary, zero out
> > all references to it. The binary will go away immediately.
> 
> Well.. The only place where the reference count is decremented is in the
> GC and when a process dies.
> To manually decrement the reference count and promise the system to never
> use the address again is not a verry functional way of doing things.
> .joppe
> 
> >
> > (This might be impossible if the reference is created as an intermediate
> > result. It might also interfere with tail recursion. Using reference
> > counts in a functional language doesn't strike me as a particularly good
> > solution in this light...)
> >
> > Regards,
> > Jo
> >
> 
>     __
> ___(  |_______________________  _______________________________________________
>     | | ,---. ,--.,--.,--.   ( (
>     | ||  _  || o ) o ) p )   ) ) "Beware of bugs in the above code;
>     | || (_) || r'| r'| -×--.( (  I have only proved it correct, not tried it."
> o,--' | `---' |_| |_| `-----' ) )                               -- Donald Knuth
> _`----'______________________( (_______________________________________________
> Jesper Wilhelmsson, jesperw@REDACTED                         +46 (0)18 471 1046
> Computing Science Department, Uppsala University, Sweden     +46 (0)733 207 207
> -------------------------------------------------------------------------------
> 

-- 
Björn Gustavsson            Ericsson Utvecklings AB
bjorn@REDACTED      ÄT2/UAB/F/P
			    BOX 1505
+46 8 727 56 87 	    125 25 Älvsjö