Feature #19610: GC.delay_promotion

• Status: Rejected
• Assignee: -
• Target version: -

[peterzhu2118 (Peter Zhu)]

GitHub Pull Request: https://github.com/ruby/ruby/pull/7683

I'm proposing GC.delay_promotion, which is a feature that changes characteristics of the garbage collector.

When set to false (the default value), the GC keeps the original behavior. This means that references from an old object to a write barrier protected young object will immediately promote the young object. References from an old object to a write barrier unprotected object will place the write barrier unprotected object in the remember set for marking during minor collections.

When set to true, references from an old object to a write barrier protected young object will not immediately promote the young object. Instead, the young object will age just like any other object, meaning that it has to survive three collections before being promoted to the old generation. References from an old object to a write barrier unprotected object will place the parent object in the remember set for marking during minor collections. This allows the child object to be reclaimed in minor collections at the cost of increased time for minor collections.

On one of Shopify's highest traffic Ruby apps, Storefront Renderer, we saw significant improvements after deploying this feature in production. In the graphs below, we compare the GC time and response time of web workers that have GC.delay_promotion = false (non-experimental group) and GC.delay_promotion = true (experimental group). We see that with this feature we spend significantly less time in the GC, 0.81x on average, 0.88x on p99, and 0.45x on p99.9.

This translates to improvements in average response time (0.96x) and p99 response time (0.92x).

In benchmarks, this feature performs better in some scenarios and worse in others. However, these benchmarks are usually not a good indicator as there are few old objects and major collections are not a significant bottleneck.

--------------  -----------  ----------  ---------  -----------  ----------  ---------  --------------  -------------
bench           master (ms)  stddev (%)  RSS (MiB)  branch (ms)  stddev (%)  RSS (MiB)  branch 1st itr  master/branch
activerecord    70.7         0.2         54.4       70.5         0.3         54.7       1.01            1.00
erubi_rails     20.5         2.0         103.0      20.7         2.2         102.2      0.94            0.99
hexapdf         2470.1       0.3         275.6      2475.4       0.7         215.9      1.03            1.00
liquid-c        65.2         1.4         39.8       65.4         0.3         39.7       1.05            1.00
liquid-compile  59.5         3.4         38.9       57.5         3.0         38.3       0.99            1.04
liquid-render   164.3        1.1         36.1       159.8        0.2         35.5       1.02            1.03
mail            135.7        0.2         50.2       135.3        0.1         50.0       1.00            1.00
psych-load      2053.0       0.0         36.4       2003.3       0.1         35.3       1.03            1.02
railsbench      2001.8       0.7         107.1      1965.1       0.0         107.3      1.00            1.02
ruby-lsp        67.1         8.7         94.6       65.1         0.8         92.8       0.97            1.03
sequel          72.4         0.2         40.4       71.3         0.2         40.4       1.01            1.02
--------------  -----------  ----------  ---------  -----------  ----------  ---------  --------------  -------------

[byroot (Jean Boussier)]

Is there really a substantial benefit in putting it behind a flag?

From my understanding, old objects for the most part are assumed stable, so promoting young objects early make minor GC a bit faster during boot, but that's about it.

I'd be in favor of just making this the new behavior.

[peterzhu2118 (Peter Zhu)]

I think this will be beneficial to most Rails apps (and probably most workloads in general), so I do agree that it would be a good idea to enable this by default and possibly make this the only option (and that way we don't need to introduce a new API).

[ko1 (Koichi Sasada)]

On my understanding, this proposal is for an object which are marked by an old object, and do not promote it immediately but increment age of the object. remember set (bitmap) keeps to refer this object and next minor GC marks this object again.
If this object is not so long living (for example, surviving 1 GC, but dead before 2nd GC), it can affect.
If this object has long lifetime (> 4 GCs), it doesn't affect.

• Pros.
  • old objects will be reduced.
  • major GC counts will be reduced because of
• Cons.
  • minor GC can increase marking time because of remembered objects.

---

If my understanding is correct, can we measure some values (major GC counts per minor GC and so on?) to proof that?

[byroot (Jean Boussier)]

If my understanding is correct,

It is.

can we measure some values (major GC counts per minor GC and so on?) to proof that?

We won't be able to get that data in time for the developer meeting but we could probably get it in a week or two.]

However I think the graphs of time spent in GC @peterzhu2118 (Peter Zhu) posted are a decent proxy of that.

[peterzhu2118 (Peter Zhu)]

In the developer meeting in Matsumoto, we discussed this ticket. We agreed that making this feature configurable makes the GC harder to use and leaked too many implementation details. We decided to instead make this feature always enabled.

I opened https://github.com/ruby/ruby/pull/7821 as an alternative where this feature is always enabled.

[byroot (Jean Boussier)]

Should we edit the title or open another ticket?

[peterzhu2118 (Peter Zhu)]

I opened #19678.

[byroot (Jean Boussier)]

• Related to Feature #19678: Don't immediately promote children of old objects added

[byroot (Jean Boussier)]

• Status changed from Open to Rejected

Ok, closing in favor of #19678 then.