Thank you for looking into this. I have been thinking about
malloc usage, and am wondering why we use malloc heavily instead
of a specialized allocator (perhaps based on dlmalloc 2.8.6,
it is small, fast, and has a good API for embedding).
Current malloc accounting has one GIANT weakness:
* We have no visibility into when malloc requests more memory
from the kernel (via mmap/sbrk). With normal object
allocation, we perform GC before allocating new object pages.
But we can't perform GC to prevent malloc from increasing
it's internal heap size via mmap/sbrk.
Disadvantage of custom allocator (over ordinary malloc):
- tools support for debugging leaks and errors requires more work.
However, I know valgrind can be made to work with custom allocators
There'll also be compile-time option to use system malloc for
testing and for error checking (e.g. OpenBSD malloc)
Old malloc accounting may always be supported for C extension
compatibility, but reliance on it will be less. Basically,
same compatibility+migration strategy as RGenGC.
Also, for future APIs, I suggest including owner VALUE as an
argument for *alloc functions. I think we can give hints to
prioritize sweeping for heap_pages with the biggest *alloc
users. And maybe pass `ec' around, too for thread-safety if
multiple mspace:
/* VALUE owner is a hint, may be ignored */
void *rb_mspace_alloc(rb_execution_context *ec, VALUE owner, size_t size);
void rb_mspace_free(rb_execution_context_t *ec, VALUE owner, void *ptr);
Anyways, the data you gather from this patch should be useful regardless.
Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>