From: Eric Wong Date: 2018-06-22T08:24:42+00:00 Subject: [ruby-core:87596] Re: [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase Koichi Sasada wrote: > Sorry for late response. No problem. > 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? So revert r48603? (commit 3a26241da3aec3d20dfc408a32de1c539455c89b) It should reduce fragmentation, but maybe we won't need to change things with transient heap. > > 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. My theory was short-lived objects can be freed first, so we try to optimize order of pages in sweeping phase to favor pages with newest (and theoretically shortest-lived) objects. I didn't find any improvement from gcbench-rdoc, though (but maybe my patch is bogus): https://80x24.org/spew/20180622081017.20225-1-e@80x24.org/raw Your transient heap idea seems much better than anything I've thought of, so lets focus on that :) Unsubscribe: