[#64210] Asking for clarification for exception handling usage — Rodrigo Rosenfeld Rosas <rr.rosas@...>
I've created a ticket for that but didn't get any feedback so I decided
[#64517] Fw: Re: Ruby and Rails to become Apache Incubator Project — Tetsuya Kitahata <[email protected]>
What do you think? >> Ruby developers
What benefits are there to this? I have a feeling that adding unnecessary
On Sat, 23 Aug 2014 22:43:46 -0700
Here I am a Japanese. Before moving anywhere else answer to our question first: what benefits?
tax issue with each other.
[#64614] cowspace (work-in-progress) — Eric Wong <normalperson@...>
Hi all, I started working on a cowspace branch. Based on the mspace API
[#64615] [ruby-trunk - Feature #10181] [Open] New method File.openat() — oss-ruby-lang@...
Issue #10181 has been reported by Technorama Ltd..
I like this feature.
On 08/28/2014 02:53 PM, Eric Wong wrote:
Joel VanderWerf <[email protected]> wrote:
On 08/29/2014 12:55 AM, Eric Wong wrote:
Joel VanderWerf <[email protected]> wrote:
[#64627] [ruby-trunk - Feature #10182] [PATCH] string.c: move frozen_strings table to rb_vm_t — ko1@...
Issue #10182 has been updated by Koichi Sasada.
[#64671] Fwd: [ruby-changes:35240] normal:r47322 (trunk): symbol.c (rb_sym2id): do not return garbage object — SASADA Koichi <ko1@...>
Why this fix solve your problem?
(2014/08/30 8:50), SASADA Koichi wrote:
SASADA Koichi <[email protected]> wrote:
Eric Wong <[email protected]> wrote:
(2014/08/31 0:18), Eric Wong wrote:
[ruby-core:64481] Re: [ruby-trunk - Feature #9113][Open] Ship Ruby for Linux with jemalloc out-of-the-box
SASADA Koichi <[email protected]> wrote: > 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. ko1: any progress on this front? I may use dlmalloc mspace API[1] to make a special CoW-friendly heap for read-only parts of the iseq structure (and probably other read-only data such as frozen pathnames). And continue using regular malloc (e.g. jemalloc) for r/w heap. [1] ftp://gee.cs.oswego.edu/pub/misc/malloc.c