[#62297] Re: [ruby-cvs:52906] nari:r45760 (trunk): * gc.c (gc_after_sweep): suppress unnecessary expanding heap. — Eric Wong <normalperson@...>
nari@ruby-lang.org wrote:
7 messages
2014/05/02
[#62307] Re: [ruby-cvs:52906] nari:r45760 (trunk): * gc.c (gc_after_sweep): suppress unnecessary expanding heap.
— SASADA Koichi <ko1@...>
2014/05/03
(2014/05/03 4:41), Eric Wong wrote:
[#62402] Re: [ruby-cvs:52906] nari:r45760 (trunk): * gc.c (gc_after_sweep): suppress unnecessary expanding heap.
— Eric Wong <normalperson@...>
2014/05/05
SASADA Koichi <ko1@atdot.net> wrote:
[#62523] [ruby-trunk - Feature #9632] [PATCH 0/2] speedup IO#close with linked-list from ccan — ko1@...
Issue #9632 has been updated by Koichi Sasada.
3 messages
2014/05/11
[#62556] doxygen (Re: Re: [ruby-trunk - Feature #9632] [PATCH 0/2] speedup IO#close with linked-list from ccan) — Tanaka Akira <akr@...>
2014-05-11 8:50 GMT+09:00 Eric Wong <normalperson@yhbt.net>:
3 messages
2014/05/13
[#62727] [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl — Eric Wong <normalperson@...>
rb_unlink_method_entry may cause old_me to be swept before the new
7 messages
2014/05/24
[#63039] Re: [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl
— SASADA Koichi <ko1@...>
2014/06/10
Hi,
[#63077] Re: [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl
— Eric Wong <normalperson@...>
2014/06/10
SASADA Koichi <ko1@atdot.net> wrote:
[#63086] Re: [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl
— SASADA Koichi <ko1@...>
2014/06/11
(2014/06/11 4:47), Eric Wong wrote:
[#63087] Re: [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl
— Eric Wong <normalperson@...>
2014/06/11
SASADA Koichi <ko1@atdot.net> wrote:
[#62862] [RFC] README.EXT: document rb_gc_register_mark_object — Eric Wong <normalperson@...>
Any comment on officially supporting this as part of the C API?
5 messages
2014/05/30
[ruby-core:62733] Re: [ruby-trunk - Feature #9113] Ship Ruby for Linux with jemalloc out-of-the-box
From:
Eric Wong <normalperson@...>
Date:
2014-05-25 01:38:53 UTC
List:
ruby-core #62733
KOSAKI Motohiro <kosaki.motohiro@gmail.com> wrote: > Do we have only one benchmark provided by Sam? I don't think it is > enough much comparison to make decision. Empirical evidence on my 32-bit yahns server after running several days shows ~40M RSS w/ jemalloc 3.0/3.6 vs 60-80M RSS for eglibc malloc on Debian stable. I'll work on gathering more data for other systems. > Anyway, I don't think Linux distros enable jemalloc because of their > packaging policy even if we enable by default. I know distros do not like bundling extra libs, but I'm not aware of policies against extra linkage for already packaged libraries. Looking at Debian stable packages, both redis and varnish packages[1] use jemalloc on common architectures. For redis, Debian just favors the system jemalloc instead of the bundled one. > So we need, at least > 1. A way to disable it My patch respects the --without-jemalloc option > 2. Easy to detect which malloc is used from bug reports. For our maintenance. rb_bug already shows dynamically loaded libraries. My patch only enables dynamic link by default. [1] http://http.us.debian.org/debian/pool/main/r/redis/redis_2.4.14-1.dsc http://http.us.debian.org/debian/pool/main/r/redis/redis_2.4.14.orig.tar.gz http://http.us.debian.org/debian/pool/main/r/redis/redis_2.4.14-1.debian.tar.gz http://http.us.debian.org/debian/pool/main/v/varnish/varnish_3.0.2-2+deb7u1.dsc http://http.us.debian.org/debian/pool/main/v/varnish/varnish_3.0.2.orig.tar.gz http://http.us.debian.org/debian/pool/main/v/varnish/varnish_3.0.2-2+deb7u1.debian.tar.gz