[#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:64629] Re: cowspace (work-in-progress)
Some comments: Basically, great points. (2014/08/28 18:10), Eric Wong wrote: > The idea is to have a separate malloc space for long-lived, WORM (write once, read many) data which may increase memory sharing for forked processes. Basically, "Write once" is important. Not for read many, isn't it? Maybe there are several abilites for memory blocks: - life time short - long - eternal - write frequency many - a few - once - read many many - a few - once - nothing - size variable size - fixed size String buffer seems [lifetime: short, write: a few, read: many, size: variable]. So String is out of scope. Current rb_iseq_t is [lifetime: long, write: a few, read: a few (depends on which method), size: fixed]. Bytecode refered from rb_iseq_t is [lifetime: long, write: once, read: a few (depends...), size: variable]. fixed size block can be aggregate (with another space with mspace or buffering technique) to avoid fragmentation. So I assume the target of this API is such as bytecode, isn't it? > The mspace API is similar to normal malloc: > > malloc(size) => mspace_malloc(GET_VM()->cowspace, size) > free(ptr) => mspace_free(GET_VM()->cowspace, ptr) > ... Does mspace API supports to detect CoW breaking *writing*? Or programmer should predicate that this area is WORM area? Another consideration is that it seems depends on dlmalloc. How is portability? (sorry I don't know about dlmalloc library more). > There are rb_cow_(malloc/free/...) function wrappers as well > as COW_(ALLOC/ZALLOC) macros to ease migrations. I don't like _cow_ prefix because cow is purpose, does not represent the ability of memory block. But it is not important before the merge. > However, I haven't found any benefits, yet. _Maintaining_ > CoW-friendliness is difficult in long-term so it might not be worth it > (compared to overall memory reductions). For ISeq, we need to change ISeq data structure to avoid write. I believe this is my task. (sorry for late) -- // SASADA Koichi at atdot dot net