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.
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.
It causes system call and extra overhead so that I'm not sure
it is acceptable.
On previous proposal I could measure some performance down on
fine-grain madvise.
OK. I am worried about that, too.
For this, I think we can also track age of page in tomb before
deciding to free or madvise. That can also reduce fragmentation
from the "aligned_free && memalign soon-after" case.
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...
One major question to ask is: does object count during
application lifetime vary enough to justify freeing
"struct heap_page_body"?
In my experience, object count is relatively stable
once an application reaches steady state, and we don't
benefit from freeing heap_page_body.
Good question. Applications have their own characteristics of memory
usage and have suitable memory management strategy.
But then, maybe some weird applications allocate many objects at
startup, and steady state object count is much smaller than
startup.
or, special cases (like requests to admin page) can increase objects.
Updated by 
Updated by