[#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:86927] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC

From: Eric Wong <normalperson@...>
Date: 2018-05-07 09:51:41 UTC
List: ruby-core #86927
Koichi Sasada <ko1@atdot.net> wrote:
> On 2018/05/05 6:32, Eric Wong wrote:
> >Also, I think we need to start GC if no sweeping/marking is
> >inprogress.
> 
> This is a problem we need to discuss.
> 
> Good: It can increase GC cleaning without additional overhead.
> 
> Bad1: However if we kick unnecessary GCs it should be huge penalty.

Right.  Minor GC is still expensive, I wonder if we can make it
cheaper or semi-incremental.  It can be incremental until next
newobj_of happens, at which point newobj_of must finish the
minor GC immediately.  This may help some IO cases if object
creation can be avoided.

For tracking GC statistics, we should probably keep them in
rb_execution_context_t instead of current globals using atomics.
To recover the most memory from GC, we want to do gc_mark_roots

1) from the ec with the most allocations
2) when it is at the shallowest stack point

This is tricky in MT situations :<

> Bad2: Also if we run multiple Ruby processes, it can be system's overhead
> which consumes CPU resources which other process can run.

I hope this feature can reduce the use extra processes, even.
In other words, instead of having an N:1 process:core ratio, it
could become (N/2):1 or something.

Now I need sleep myself :<

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

In This Thread