ruby-core

Koichi Sasada <ko1@atdot.net> 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: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>