Issue #14955 has been updated by ko1 (Koichi Sasada).


off-topic `:p`:

If we have a lightweight communication channel between user-process and OS, we can choose this technique harder.

https://www.azul.com/files/c4_paper_acm2.pdf propose to add sharing remap table between OS and user process to achieve fine-grained page control.

(but they chosen not-modify linux after that)

For example, if user process manage "free-able pages" list in user-process (register this page map by a system call at once) and OS can check it when system memory (OS managed memory) is tight, it is best. of course, this simple model has race issue and some other issues...


----------------------------------------
Feature #14955: [PATCH] gc.c: use MADV_FREE to release most of the heap page body
https://bugs.ruby-lang.org/issues/14955#change-73370

* Author: normalperson (Eric Wong)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
gc.c: use MADV_FREE to release most the heap page body

On x86 and x86-64 Linux and FreeBSD (at least), we can release
most of the heap page body (12k of nearly 16k).  This is better
than causing malloc fragmentation with free(3) on memaligned areas.

cf. https://sourceware.org/bugzilla/show_bug.cgi?id=14581

Note: memory is memory to madvise(2), regardless of whether it
came from brk(2) or mmap(2); so we expect to be able to madvise
any anonymous segments as long as they're page-aligned.
Allocators configured to file-backed mappings will cause
warnings when $VERBOSE is set.


---Files--------------------------------
0001-gc.c-use-MADV_FREE-to-release-most-the-heap-page-bod.patch (5.78 KB)


-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>