Project

General

Profile

Actions

Feature #19678

closed

Don't immediately promote children of old objects

Added by peterzhu2118 (Peter Zhu) 10 months ago. Updated 9 months ago.

Status:
Closed
Assignee:
-
Target version:
-
[ruby-core:113513]

Description

This is an alternate proposal to #19610 where the feature is not configurable and always enabled.

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

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
--------------  -----------  ----------  ---------  -----------  ----------  ---------  --------------  -------------

Files


Related issues 1 (0 open1 closed)

Related to Ruby master - Feature #19610: GC.delay_promotionRejectedActions
Actions #1

Updated by byroot (Jean Boussier) 10 months ago

Actions #2

Updated by peterzhu2118 (Peter Zhu) 9 months ago

  • Status changed from Open to Closed

Applied in changeset git|e87f6c899e55f4d9452ce4d75cf2a725ae736aff.


Don't immediately promote children of old objects

[Feature #19678]

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. We compare the GC time and response time of web workers that
have the original behaviour (non-experimental group) and this new
behaviour (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).

Actions

Also available in: Atom PDF

Like0
Like0Like0