From: SASADA Koichi <ko1@...>
Date: 2014-02-26T02:35:10+09:00
Subject: [ruby-core:61084] Re: [ruby-trunk - Feature #9113][Open] Ship Ruby for Linux with jemalloc out-of-the-box

(2014/02/19 9:08), Eric Wong wrote:
> Btw, I also hope to experiment with a slab allocator since many internal
> objects are around the same size (like an OS kernel).  This idea is
> originally from the Solaris kernel, but also in Linux and FreeBSD.  One
> benefit with slab allocators over a general purpose malloc is malloc
> has too little context/information make some decisions:
> 
> * long-lived vs short-lived (good for CoW)
> * shared between threads or not
> * future allocations of the same class
> 
> Notes on slab: I don't think caching constructed objects like the
> reference Solaris implementation does is necessary (or even good),
> since it should be possible to transparently merge objects of different
> classes (like SLUB in Linux, I think).
> 
> Anyways, I think jemalloc is a great general-purpose malloc for things
> that don't fit well into slabs.  And it should be easy to let a slab
> implementation switch back to general-purpose malloc for
> testing/benching.
> 

Recently I'm working around this topic.

(1) Life-time oriented, similar to Copying GC
(2) CoW frindly (read only) memories

More detail about (2):
The following figure shows the stacked memory usage (snapshot) collected
by valgrind/massif, on discorse benchmark by @sam's help.
http://www.atdot.net/fp_store/f.69bk1n/file.copipa-temp-image.png

Interestingly, 50MB is consumed by iseq (iseq.c, compile.c). Most of
data are read only, so it can be more CoW frindly. Now, we mixes
read-only data and r/w data such as inline cahce.

There are several ideas.  And I belive it is good topic to consider for
Ruby 2.2.

-- 
// SASADA Koichi at atdot dot net