I wrote:
> Also, I think it would be beneficial to check malloc_increase
> and do a lazy sweep step BEFORE calling malloc, since that should
> improve cache locality in malloc (because they're usually LIFO).

Unfortunately, adding lazy sweep steps (gc_sweep_continue) doesn't
seem to work well under malloc pressure.  The problem seems to
be the order of heap->pages is fixed when pages are added to the
heap, and lazy sweep always walks them in newest-to-oldest order;
not MRU order, even.

This means calling gc_sweep_continue inside
objspace_malloc_increase when malloc_increase > 4096 (or any
number BEFORE malloc_limit to reduce pause under gc_rest)
doesn't always free the heaps with the biggest malloc-ed areas.

Now, I wonder; what if we start tracking malloc usage at a
per-heap_page level?  It would require internal API changes so
we can quickly figure out which heap_page the malloc-ed pointer
would go to:

   void *rb_malloc(VALUE obj, size_t size);
   void *rb_realloc(VALUE obj, void *ptr, size_t size, size_t old_size);
   void *rb_calloc(VALUE obj, size_t nmemb, size_t size);
   void rb_free(VALUE obj, void *ptr, size_t n);

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