[erlang-questions] Garbage Collector Details

[Jesper Louis Andersen]

On Fri, Sep 9, 2011 at 19:55, Jon Watte <jwatte@REDACTED> wrote:

> Is there a global lock for allocating these fragments, or is the heap
> fragment allocator smarter than this? How is contention for this allocator
> resolved?

Rickard Green is the right guy here, because he wrote the allocator
framework. But you can in general use the same tricks as is done by
parallel malloc() implementations. The idea is to split the (operating
system) heap up into arenas and make each thread go to a different
arena. This way, by default, lock contention is kept low since you
will usually not have to compete for the lock at all and you can get
your allocation done, free the lock and go on. Notice that you can get
the uncontended lock/unlock case fast by using e.g., the linux
futex(7) calls in which case uncontended locking doesn't even need the
kernel involved.

More advanced allocators keep a local thread cache of recently free'd
objects which are allocated in an arena. So rather than give back such
an object to the Arena as it is freed, the thread speculates that the
object will be allocated again soon and keeps it in the thread as if
it were allocated. Requests of an object whose size is in the cache
already can skip the synchronization completely because the thread
already has it, out of the main arena. This solution is also extremely
(CPU) cache-friendly since a recently released object is more commonly
in the (CPU) cache. I can imagine this is fairly easy to do when you
are allocating data for a Garbage Collector process heap because
objects will not have extremely fine granularity but be a bit more
coarse, and often be of certain fixed sizes.

One very cool thing about Erlang is that the erts_alloc framework is
plugin-based. You can configure it and tune it if you need it. I can
also imagine it is a very important part of coming SMP improvements.

-- 
J.