[erlang-questions] ets vs list

[Ulf Wiger]

On 09/13/2010 04:41 PM, Morten Krogh wrote:
>  What exactly does it mean that data residing in ets isn't
>  garbage collected?
> 
> Does it mean that if a {key, Value} pair is in the ets table T,
> and I write
> 
> ets:delete(T, Key)
> 
> then Value will not be garbage collected.
> 
> Morten.

If you delete an object from an ets table, it will be freed
on the spot - think malloc/free.

If you don't explicitly delete it, it will stay there, and
will never be touched by a garbage collector. The garbage
collector cares about process heaps and binaries, but not
about ets. Once an object is copied into ets, it is outside
the jurisdiction of the GC; when read from ets, it is copied
onto the process heap, and this copy becomes subject to GC.

Erlang's per-process garbage collector periodically copies
live data to a new instance of the process heap. There are
a few variations of the theme, but basically, that's how
it works. When some data is no longer referenced, it becomes
garbage on the heap, and eventually, the heap will fill up
with garbage and live data, triggering the garbage collector.

In this sense, GC is really a misnomer, since it collects,
and copies, live data, rather than messing about with the
garbage. This is also the reason why GC cost can be said
to be proportional to the amount of live data, rather than
the amount of garbage. Producing lots of garbage, though,
will trigger GC more frequently, causing more scans and
copying of the live data.

BR,
Ulf W