[#86787] [Ruby trunk Feature#14723] [WIP] sleepy GC — ko1@...

Issue #14723 has been updated by ko1 (Koichi Sasada).

13 messages 2018/05/01
[#86790] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC — Eric Wong <normalperson@...> 2018/05/01

ko1@atdot.net wrote:

[#87095] [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase — ko1@...

Issue #14767 has been updated by ko1 (Koichi Sasada).

9 messages 2018/05/17

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

From: Eric Wong <normalperson@...>
Date: 2018-05-21 05:20:02 UTC
List: ruby-core #87210
Юрий Соколов <funny.falcon@gmail.com> wrote:
> > Eric Wong <normalperson@yhbt.net> wrote:
> >
> > Reverted for now because of regressions in:
> >
> >             bm_array_sample_100k__6k
> >             bm_array_sample_100k___10k
> >             bm_array_sample_100k___50k
> >
> > I think the original unsigned + underflow avoidance code
> > prevented us from accounting free() properly, and we were
> > triggering GC more as a result.

> Why triggerring GC less frequently considered as disadvantage?

Memory usage got way high; I think those tests were around 8x
more memory AND 15% slower.

Of course too-frequent GC is bad, too; because it costs cycles,
and hurts locality; so we still need to find the right balance.

> I think, real aplications will benefit from it.
> Why this benchmarks suffers from it?

I think a big problem now is lazy sweeping isn't granular enough
and happens too late, increasing the chance of malloc
fragmentation.

We pay a huge cost for malloc accounting(*) but barely use that
data for making GC decisions.

(*) https://bugs.ruby-lang.org/issues/10238

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

In This Thread