[ruby-core:87594] Re: [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase

Sorry for late response.

On 2018/06/13 18:59, Eric Wong wrote:
> Unfortunately, adding lazy sweep steps (gc_sweep_continue) doesn't
> seem to work well under malloc pressure.

One simple solution is disable lazy sweep if GC reason is malloc 
(malloc_increase). Not so much cases, so that it can be acceptable. How 
about it?

> 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.

Does MRU (or order) affect performance?

https://en.wikipedia.org/wiki/Cache_replacement_policies#Most_recently_used_(MRU)

introduced some examples, however I'm not sure it fits MRI.

> 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);

I doubt about this idea because we need additional computation and 
storage size.

* Keep per-heap_page malloc'ed size (overhead on each malloc/free)
* Order by per-heap_page malloc'ed size

IMO these cost doesn't pay for overall performance.

API can be replaced. But not for this idea, IMO.

-- 
// SASADA Koichi at atdot dot net

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