From: Eric Wong Date: 2018-06-20T08:54:26+00:00 Subject: [ruby-core:87528] Re: [Ruby trunk Feature#14857] collect malloc info 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: