[#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:87189] Re: [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase

From: Юрий Соколов <funny.falcon@...>
Date: 2018-05-19 06:15:07 UTC
List: ruby-core #87189
пт, 18 мая 2018 г., 11:47 Eric Wong <normalperson@yhbt.net>:

> Eric Wong <normalperson@yhbt.net> wrote:
> > OK.  Also, did we ever consider signed type (`ssize_t`) for malloc
> > counters instead?  This may be more useful if we switch to
> > thread-local storage for counters to avoid atomics.
>
> 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.
>
> With this patch, frees are accounted properly so malloc_increase
> grew too slowly...
>

Why triggerring GC less frequently considered as disadvantage?
I think, real aplications will benefit from it.
Why this benchmarks suffers from it?


> Also, I think it would be beneficial to check malloc_increase
> and do a lazy sweep step BEFORE calling malloc, since that should
> improve cache locality in malloc (because they're usually LIFO).
>
> Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>
>

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

In This Thread