Issue #9113 has been updated by Eric Wong.


 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.

----------------------------------------
Feature #9113: Ship Ruby for Linux with jemalloc out-of-the-box
https://bugs.ruby-lang.org/issues/9113#change-45479

* Author: Sam Saffron
* Status: Feedback
* Priority: Normal
* Assignee: 
* Category: build
* Target version: 
----------------------------------------
libc's malloc is a problem, it fragments badly meaning forks share less memory and is slow compared to tcmalloc or jemalloc. 

both jemalloc and tcmalloc are heavily battle tested and stable. 

2 years ago redis picked up the jemalloc dependency see: http://oldblog.antirez.com/post/everything-about-redis-24.html 

To quote antirez:
``
But an allocator is a serious thing. Since we introduced the specially encoded data types Redis started suffering from fragmentation. We tried different things to fix the problem, but basically the Linux default allocator in glibc sucks really, really hard. 
``

--- 

I recently benched Discourse with tcmalloc / jemalloc and default and noticed 2 very important thing: 

median request time reduce by up to 10% (under both)
PSS (proportional share size) is reduced by 10% under jemalloc and 8% under tcmalloc.

We can always use LD_PRELOAD to yank these in, but my concern is that standard distributions are using a far from optimal memory allocator. It would be awesome if the build, out-of-the-box, just checked if it was on Linux  (eg: https://github.com/antirez/redis/blob/unstable/src/Makefile#L30-L34 ) and then used jemalloc instead. 



-- 
http://bugs.ruby-lang.org/