[#74190] [Ruby trunk Feature#12134] Comparison between `true` and `false` — duerst@...
SXNzdWUgIzEyMTM0IGhhcyBiZWVuIHVwZGF0ZWQgYnkgTWFydGluIETDvHJzdC4KCgpUc3V5b3No
3 messages
2016/03/07
[#74269] Type systems for Ruby — Rob Blanco <ml@...>
Dear ruby-core,
5 messages
2016/03/10
[#74395] [Ruby trunk Feature#12142] Hash tables with open addressing — shyouhei@...
Issue #12142 has been updated by Shyouhei Urabe.
3 messages
2016/03/17
[ruby-core:74748] Re: [Ruby trunk Feature#12236] Introduce `mmap` managed heap
From:
Eric Wong <normalperson@...>
Date:
2016-03-31 17:17:37 UTC
List:
ruby-core #74748
[email protected] wrote: > * We need to manage x4 more pages. We need to avoid O(n) (n: > page number) operations from the GC process. I think we can use ccan/list with O(1) insert/delete without iterations instead of relying on flags.allocated scanning. (this has cost of higher per-page metadata overhead) We may also rely on ccan/list in other places for branchless insert/delete instead of relying on flags. ccan/list is slower for iteration than custom list (as I demonstrated for compile.c), but easier+faster for insert/delete. > * Difficult to port on a system which doesn't have `mmap` > (or similar API) I don't think we need to worry about those; but perhaps we fall back to posix_memalign and skip madvise calls to return memory back to OS that way. > * We consume huge virtual memory (at least 256MB). But > anybody worries about that? We need a smaller space for 32-bit, I think. Why was 256MB chosen in the first place? I run a lot of small scripts that won't even need 1/10th of that. General comment: can we please maintain 80-column limit? Some of us have bad eyesight and need big fonts even with giant monitors. Thanks. Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>
