[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.

I believe we don't have any drawback with 256MB virtual memory allocation. (but it can depend on OSs)

It may depends on devices: one may wish to run ruby script on MIPS linux box with 64MB memory.
Doubtfully, kernel will be configured with over-commit on such system.

Does it really matters for performance ARENA_SIZE to be 256MB ?
May be it could be as small as 4MB without noticeable degradation?
Or may it be compile-time parameter with access from configure and default to 256MB?

Yura Sokolov wrote:

I believe we don't have any drawback with 256MB virtual memory allocation. (but it can depend on OSs)

It may depends on devices: one may wish to run ruby script on MIPS linux box with 64MB memory.
Doubtfully, kernel will be configured with over-commit on such system.

Does it really matters for performance ARENA_SIZE to be 256MB ?
May be it could be as small as 4MB without noticeable degradation?
Or may it be compile-time parameter with access from configure and default to 256MB?

Well, as long as your Ruby process never actually needs more than 64MB of memory, that's not a problem, right? And I don't think there's any safeguards in Ruby today against overcommit anyway, so I don't see how this proposal is any different in that regard (but maybe I misunderstand).

I guess it would break if the OS has overcommit protections enabled. Example: vm.overcommit_memory 2 on Linux. But I don't think this is a common case?