From: Koichi Sasada Date: 2018-06-22T16:17:05+09:00 Subject: [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: