properties using * selector have more memory pressure since chromium 127 released

[rogerleung0411]

Background

Recently we encountered a Chrome OOM issue, before starting this discussion, i've created a Chromium issue and discussed a lot with Chromium CSS team, here's the issue: https://issues.chromium.org/issues/368341452.

I'm gonna explain furthermore in the next section. There was no update in the issue since Oct 12, i'm looking for you guys for better help. I think maybe there's something tailwind can do to workaround, or giving more details to Chromium CSS team to fix this issue (maybe..).

How to repro Chromium's OOM

steps:

• Download the crash_minimum_repro.zip from comment # 9, or crash_minimum_repro.zip (recommended)
• Open the .html
• [Optional] Open the devtool panel may repro more easily.
• Frequently toggle the button Toggle Tailwind CSS Style in top (which will append / remove the specific <style /> contains tailwind output)
• CPU usage and memory go up by quite a bit, and Chrome may OOM in most devices.

a screen record below shows this procedure too, also mentioned in comment 10. ERROR_CODE 5 means OOM.

chrome.oom.record.mp4

Information i have for the time being

• For the example page, Firefox Nightly 132.0a1 (2024-09-26) roughly 190MB peak memory usage. However Chrome is going as high as 1.4G before dropping back to about 340MB .
• Chromium landed a CSS performance optimization in Chromium 127 (commit here). I think it's related but not really confirmed.
• Tailwind's output below maybe affected, since they are attached to all DOM elements (with * selector).

*, ::before, ::after {
  --tw-ring-inset:  ;
  --tw-ring-offset-width: 0px;
  --tw-ring-offset-color: #fff;
  --tw-ring-color: rgb(59 130 246 / 0.5);
  --tw-ring-offset-shadow: 0 0 #0000;
  --tw-ring-shadow: 0 0 #0000;
  /* ... more */
}

• Chromium CSS Team member confirmed that they "have an issue with StyleInheritedVariables, that if an element with a large amount of custom properties we can allocate ~kBs per computed style object. Our optimization works well if we have lots of variables on the :root. Likely the switch to oilpan has created more pressure as not on a separate heap anymore" (comment 17). I think the "optimization" here refers to the commit list above.

I'm seeking help and wanna know:

• Can properties like --tw-ring-inset, --tw-ring-offset-width, --tw-ring-offset-color, ..etc, apply to :root instead of *? I'm not sure whether these properties are inheritable or not? I confirmed that css above with * selector exist since tailwind 2.0 , and 4.0(in branch next) perisists.
• I found there's abilities to make properties to be inheritable:

  tailwindcss/packages/tailwindcss/src/ast.ts

  Lines 183 to 187 in b701ed6

  	if (inherits) {
  	propertyFallbacksRoot.push(decl(property, initialValue ?? 'initial'))
  	} else {
  	propertyFallbacksUniversal.push(decl(property, initialValue ?? 'initial'))
  	}

  , while diving into all source code i CAN NOT clearly distinguish when will the if block be true. Should inheritable properties all be true? (currently all with 'false' in utilities layer)：
  

  tailwindcss/packages/tailwindcss/src/utilities.ts

  Line 90 in b701ed6

  decl('inherits', 'false'),

[adamwathan]

Thank you for raising this — escalating it with my contacts on the Chrome team to see if we can figure out a quick resolution.

[adamwathan]

Can properties like --tw-ring-inset, --tw-ring-offset-width, --tw-ring-offset-color, ..etc, apply to :root instead of *? I'm not sure whether these properties are inheritable or not? I confirmed that css above with * selector exist since tailwind 2.0 , and 4.0(in branch next) perisists.

Everything needs to be on * I'm afraid because it's important that they don't inherit. In v4 we use @property for this but provide a fallback using * just for Firefox, which is wrapped in a @supports rule that ensures the code doesn't match in Chrome/Safari so I don't think it should be an issue there. We are going to remove this fallback when v4 is tagged for real though because @property will have been available in Firefox for long enough that I feel comfortable not providing the fallback.

[rogerleung0411]

Thank you for your quick reply! If my understanding is correct, * selector will be remove when v4 is stably released? That's a good news to have! Since tailwind users are mainly using v2 or v3, i think we'd better find out a quick resolution before v4 released.

[Inwerpsel]

The commit you mention is definitely related, it changes the CSS variables data to be garbage collected (using oilpan), where before it was not.

Relevant change: https://chromium-review.googlesource.com/c/chromium/src/+/5470982/14/third_party/blink/renderer/core/style/style_variables.h#b47

My comment from another thread, quoting Chromium's commit message, is probably more relevant here.

To correctly have a unique StyleVariables data for each style
introduces has_own_*variables to keep track of the state.
(This is somewhat a bit manual which is unfortunate). This replaces
the HasOneRef call.

It seems very plausible that universal selectors don't play well with this change. If I'm reading it correctly, this should be true for every element once you start using a universal selector with custom properties. It's hard to tell from the Chromium code what would be the impact of this being true 100% of the time, but it feels like it probably breaks some optimization(s).

from #7317 (reply in thread)

In Chromium's documentation on memory management, the following sentence indicates that this type of change indeed can cause memory issues.

It is not a good idea to unnecessarily increase the number of objects managed by Oilpan. Although Oilpan implements an efficient GC, the more objects you allocate on Oilpan, the more pressure you put on Oilpan, leading to a longer pause time.

And

If the allocation rate of the object is very high, that may put unnecessary strain on the Oilpan's GC infrastructure as a whole.

Usage in a style recalculation will definitely result in a very high allocation rate at least in some cases.

[rogerleung0411]

I read your comment at that post and, yeah it's quite relevant, thanks for calling out this!

The minimum repro example and steps to reproduce the OOM i provided are simplified. The real app we built is using a lazy render strategy to render such a big table. All off-screen rows only will being rendered as soon as it nearly to be visible (using InsersectionObserver, trigger by user's scrolling event). I think this user interaction leads to "allocation rate of the object is very high". DOM nodes number highly increases to more than 30k in our app as user scroll to bottom, which puts much pressure to Oilpan. The sentences you quote are really accurate, and very helpful. Thanks a lot! I'm still seeking for a quick resolution.

[Inwerpsel]

Yeah it appears this change has reduced the amount of elements the browser can deal with before it goes OOM.

What I meant about the allocation rate is not that it would get bad upon many user interactions (it might also but that's not my point). I meant that any time the browser performs a style recalculation of all nodes on the page, it now potentially has to do an allocation per node in a very brief amount of time. Even a small page of a few hundreds DOM nodes will result in a high allocation rate during every style recalculation.

That said, 30K is much more elements than can fit on the screen, so you'd probably want some mechanism to stay below some maximum amount of DOM nodes.

[rogerleung0411]

Thanks for further explanation. :)
In such a big table scene, we are trying to unmount quite a lot of components when they turned to be invisible for a while, to reduce the total amount of DOM elements. While there’s also a DOM-based text editor using tailwind 2 too, implementing such virtualization strategy is a heavy work.

[rogerleung0411]

Edit: The Chromium optimization actually landed in version 127, as mentioned in the original Chromium issue i created.

[rogerleung0411]

Update: Chromium team fix a GC issue in commit, I've tested it in 132.0.6792.0 canary, and it feels really good, memory pressure reduced as usual.