From: Eric Wong Date: 2018-06-13T09:59:36+00:00 Subject: [ruby-core:87486] Re: [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase 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: