[#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
[#87096] Re: [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase — Eric Wong <normalperson@...> 2018/05/17

ko1@atdot.net wrote:

[ruby-core:86819] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC

From: Eric Wong <normalperson@...>
Date: 2018-05-02 05:00:14 UTC
List: ruby-core #86819
Koichi Sasada <ko1@atdot.net> wrote:
> On 2018/05/02 13:08, Eric Wong wrote:
> >Sure.  Should I commit after adding "else" to mutex_lock?
> 
> I want to ask to introduce "disable" macro (like USE_RGENGC) to measure
> impact on this technique (and disable to separate issues). Please name it as
> your favorite.

OK, I added RUBY_GC_SLEEPY_SWEEP and RUBY_GC_SLEEPY_MARK macros:

  [PATCH 6/4] gc.c: allow disabling sleepy GC
  https://80x24.org/spew/20180502045248.GA3949@80x24.org/raw

And missing "else":

  [PATCH 5/4] thread_sync.c (mutex_lock): add missing else
  https://80x24.org/spew/20180502044255.GA30679@80x24.org/raw


I also added some benchmarks, but I'm not sure if dependency on
/dev/urandom is good because performance across machines and
kernel configuration can be very different.

  https://80x24.org/spew/20180502045714.GA5427@whir/raw

I need something which:
a) doesn't compete for GVL
b) takes a while

Perhaps depending on fork() is fine, since it's just as
unportable as /dev/urandom is.

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

In This Thread