ko1 / atdot.net 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:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>