From: "sam.saffron (Sam Saffron)" <sam.saffron@...>
Date: 2012-11-30T11:02:10+09:00
Subject: [ruby-core:50358] [ruby-trunk - Feature #7472] Add a mechanism to remove objects from the GC cycle


Issue #7472 has been updated by sam.saffron (Sam Saffron).


> if you mean "move to a different memory address" this will cause crashes.

no, not at all, leave it exactly where it is, just have objectspace partitioned in 2. the refs that are "skipped" don't get scanned in the lazy sweep. 
----------------------------------------
Feature #7472: Add a mechanism to remove objects from the GC cycle
https://bugs.ruby-lang.org/issues/7472#change-34174

Author: sam.saffron (Sam Saffron)
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: 2.0.0


For typical rails apps there is a huge largely static object graph in memory. Requests come in, some objects are added, and the GC runs. 

The blocking nature of the GC introduces a jitter that stops all execution. 

In our typicalish Rails application, we see approximately 500k objects in the object space, each request add about 150k objects. On our production machine this means the GC stops execution for 30-40ms on a fairly beefy box: 

GC Profiler ran during this request, if it fired you will see the cost below:

GC 457 invokes.
Index    Invoke Time(sec)       Use Size(byte)     Total Size(byte)         Total Object                    GC Time(ms)
    1              11.169             13134480             17014400               425360        40.00200000000120326149
    2              11.249             13350000             17014400               425360        32.00199999999853162080


It is clear that introducing a full scoped generational GC is a massive undertaking, but I was thinking that certain GC apis can make application servers like thin,unicorn or puma operate way more efficiently. 

How about we add.

GC.skip(object) # remove object from GC cycle, essentially copy the ref to a place that is not scanned 
GC.queue(object) # add an object back to the GC cycle 
GC.skipped # list all the objects that are skipped


Careful use of these methods can reduce GC code by a very large amount as it would reduce fragmentation and logic required to determine if an object is alive or not. 

Application servers could keep snapshots of object ids on regular intervals and decide which ones to skip. Sure memory usage would rise, but GC blocking would decrease. 

Thoughts? 


-- 
http://bugs.ruby-lang.org/