From: Eric Wong <normalperson@...>
Date: 2018-05-01T03:18:11+00:00
Subject: [ruby-core:86790] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC

ko1@atdot.net wrote:
> My understanding, your proposal in pseudo code is (pls correct me if it is wrong):
> 

Correct.

> `gc_rest()` do all of rest steps.  Is it intentional?

I thought about that myself.  I haven't measured impact much and
decided to have less code.

We can also try the following to favor sweep before mark:
```
--- a/gc.c
+++ b/gc.c
@@ -6534,7 +6534,14 @@ rb_gc_step(const rb_execution_context_t *ec)
 {
     rb_objspace_t *objspace = rb_ec_vm_ptr(ec)->objspace;
 
-    gc_rest(objspace);
+    if (is_lazy_sweeping(heap_eden)) {
+        gc_sweep_rest(objspace);
+    }
+    else if (is_incremental_marking(objspace)) {
+        PUSH_MARK_FUNC_DATA(NULL);
+        gc_marks_rest(objspace);
+        POP_MARK_FUNC_DATA();
+    }
 
     return rb_gc_inprogress(ec);
 }
```

> Another tiny comments:
> 
> > +    static const struct timespec zero;
> 
> `zero` doesn't seem to be initialized. intentional?

Yes,  static and global are variables are auto-initialized to zero.
AFAIK this is true of all C compilers.

> Note:
> 
> After introducing Guild, getting `contended` status should be high-cost (we need to use lock to see this info).
> However, we can eliminate this check if we shrink the target: only have one Guild (== current MRI).

So one objspace will be shared by different guilds?

We may use atomics to check.  I think sweep phase can be made
lock-free in the future.

Originally I wanted to make sweep lock-free before making this
patch, but it seems unnecessary at the moment.

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