Bugzilla

BHR (Background Hang Reporter) data from nightly (2026-02-28) shows that
`<servo_arc::Arc<T> as core::ops::drop::Drop>::drop` called from
`SelectorMap<T>::clear` accounts for approximately **9.7% of all
content-process main-thread hang time** (~54,900 seconds weighted by
usage hours, ~95,700 hang events).

The call chain is:

```
servo_arc::Arc<T>::drop
 -> SmallVec<A>::drop
  -> SelectorMap<T>::clear
   -> GenericElementAndPseudoRules<T>::clear
    -> CascadeData::clear_cascade_data
```

This also appears in ShutDownKill crash data (nightly, last 7 days):
- `SelectorMap<T>::clear` as top frame: 38 kills
- `servo_arc::Arc::drop` in same path: 7 kills

The hang appears to come from dropping large numbers of Arc-wrapped
selector entries when clearing cascade data. Each entry requires an
atomic refcount decrement and potential deallocation, which adds up
when the selector maps are large.

Relevant code:
- SelectorMap::clear: https://searchfox.org/firefox-main/rev/9677c8fc008ffdbd0c7a6d83ee6434184e058e57/servo/components/style/selector_map.rs#175
- CascadeData::clear_cascade_data: https://searchfox.org/firefox-main/rev/9677c8fc008ffdbd0c7a6d83ee6434184e058e57/servo/components/style/stylist.rs#4508-4534

Related: bug 1406996 tracks crash reports in the same code path (Rust
HashMap operations), but the crashes are now very low volume (1 in 90
days). This bug is about the jank/hang impact, which is substantial.

BHR (Background Hang Reporter) data from nightly (2026-02-28) shows that
`CascadeData::clear_cascade_data` (via `Stylist::flush` /
`Servo_StyleSet_FlushStyleSheets`) contributes approximately **55 seconds**
of main-thread hang time (weighted by usage hours) in content processes.

The call chain is:

```
servo_arc::Arc<T>::drop
 -> SmallVec<A>::drop
  -> SelectorMap<T>::clear
   -> GenericElementAndPseudoRules<T>::clear
    -> CascadeData::clear_cascade_data
     -> Stylist::flush
      -> Servo_StyleSet_FlushStyleSheets
       -> ServoStyleSet::UpdateStylist()
```

This also appears in ShutDownKill crash data (nightly, last 7 days):
- `SelectorMap<T>::clear` as top frame: 38 kills
- `servo_arc::Arc::drop` in same path: 7 kills

The hang comes from dropping large numbers of Arc-wrapped selector
entries when clearing cascade data. Each entry requires an atomic
refcount decrement and potential deallocation.

For context, this is part of a broader pattern: `servo_arc::Arc::drop`
accounts for ~1,123s of total content-process hang time across all
callers. The biggest contributors are:
- RestyleManager::ProcessPostTraversal dropping old ComputedValues (~250s, 22%)
- RestyleManager::ClearServoDataFromSubtree (~150s, 13%)
- Stylist::flush / CascadeData::clear (~55s, 5%) ← this bug
- CSS parsing DeclarationBlock_Release (~30s, 3%)
- Frame destruction (~19s, 2%)

Relevant code:
- SelectorMap::clear: https://searchfox.org/firefox-main/rev/9677c8fc008ffdbd0c7a6d83ee6434184e058e57/servo/components/style/selector_map.rs#175
- CascadeData::clear_cascade_data: https://searchfox.org/firefox-main/rev/9677c8fc008ffdbd0c7a6d83ee6434184e058e57/servo/components/style/stylist.rs#4508-4534

Related: bug 1406996 tracks crash reports in the same code path (Rust
HashMap operations), but the crashes are now very low volume (1 in 90
days). This bug is about the jank/hang impact.

See also: https://fqueze.github.io/hang-stats/child/ — search for
`CascadeData` to see the hang stacks.

BHR (Background Hang Reporter) data from nightly (2026-02-28) shows that
`CascadeData::clear_cascade_data` (via `Stylist::flush` /
`Servo_StyleSet_FlushStyleSheets`) contributes approximately **55 seconds**
of main-thread hang time (weighted by usage hours) in content processes.

The call chain is:

```
servo_arc::Arc<T>::drop
 -> SmallVec<A>::drop
  -> SelectorMap<T>::clear
   -> GenericElementAndPseudoRules<T>::clear
    -> CascadeData::clear_cascade_data
     -> Stylist::flush
      -> Servo_StyleSet_FlushStyleSheets
       -> ServoStyleSet::UpdateStylist()
```

This also appears in ShutDownKill crash data (nightly, last 7 days):
- `SelectorMap<T>::clear` as top frame: 38 kills
- `servo_arc::Arc::drop` in same path: 7 kills

The hang comes from dropping large numbers of Arc-wrapped selector
entries when clearing cascade data. Each entry requires an atomic
refcount decrement and potential deallocation.

For context, this is part of a broader pattern: `servo_arc::Arc::drop`
accounts for ~1,123s of total content-process hang time across all
callers. The biggest contributors are:
- RestyleManager::ProcessPostTraversal dropping old ComputedValues (~250s, 22%)
- RestyleManager::ClearServoDataFromSubtree (~150s, 13%)
- Stylist::flush / CascadeData::clear (~55s, 5%) ← this bug
- CSS parsing DeclarationBlock_Release (~30s, 3%)
- Frame destruction (~19s, 2%)

Relevant code:
- SelectorMap::clear: https://searchfox.org/firefox-main/rev/9677c8fc008ffdbd0c7a6d83ee6434184e058e57/servo/components/style/selector_map.rs#175
- CascadeData::clear_cascade_data: https://searchfox.org/firefox-main/rev/9677c8fc008ffdbd0c7a6d83ee6434184e058e57/servo/components/style/stylist.rs#4508-4534

Related: bug 1406996 tracks crash reports in the same code path (Rust
HashMap operations), but the crashes are now very low volume (1 in 90
days). This bug is about the jank/hang impact.