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>