[#60404] is RB_GC_GUARD needed in rb_io_syswrite? — Eric Wong <normalperson@...>
I haven't gotten it to crash as-is, but it seems like we need to
4 messages
2014/02/01
[#60682] volatile usages — Eric Wong <normalperson@...>
Hi all, I went ahead and removed some use of volatile which were once
5 messages
2014/02/13
[#60794] [RFC] rearrange+pack vtm and time_object structs — Eric Wong <normalperson@...>
Extracted from addendum on top of Feature #9362 (cache-aligned objects).
4 messages
2014/02/16
[#61139] [ruby-trunk - Feature #9577] [Open] [PATCH] benchmark/driver.rb: align columns in text output — normalperson@...
Issue #9577 has been reported by Eric Wong.
3 messages
2014/02/28
[ruby-core:60851] Re: [ruby-trunk - Feature #9113][Open] Ship Ruby for Linux with jemalloc out-of-the-box
From:
Eric Wong <normalperson@...>
Date:
2014-02-19 00:08:02 UTC
List:
ruby-core #60851
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.