From: Eric Wong <normalperson@...>
Date: 2014-02-25T18:47:23+00:00
Subject: [ruby-core:61087] Re: [ruby-trunk - Feature #9113] Ship Ruby for Linux with jemalloc out-of-the-box

ko1@atdot.net wrote:
>  (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

Yes.  We should be able to do moving/defragmentation of long-lived
internal allocations, even.

>  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.

Yes, also the iseq struct is huge (300+ bytes on 64-bit).  I think we
can shrink it (like I did with struct vtm/time_object) and move r/w data
off to a different area.

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

OK; especially since this should have no public API breakage.