How much of //third_party/blink/renderer/platform/wtf is still necessary?

[Colin Blundell]

Hi folks,

+Kent Tamura's thread brought something to the forefront of my mind that I wonder about sometimes: Does anyone actively give thought/analysis to which parts of the functionality provided by //third_party/blink/renderer/platform/wtf are still actually "necessary" to provide and use separately from functionality provide by ::base and/or ::std?

Thanks,

Colin

[Kentaro Hara]

As part of the Onion Soup efforts (2015 - 2018 ish), we tried to minimize platform/wtf and merging things into ::base and ::std. We removed lots of things. I'd not say we are complete but an easy part is already done :)

The remaining ones are: Oilpan-integrated data structures, String/AtomicString-related data structures, Blink-specific data structures.

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAMGE5NESSQggSH935uT3rh4Uvct8MDuyqsrbWd_-Rhcut_GUrA%40mail.gmail.com.

--

Kentaro Hara, Tokyo

[Colin Blundell]

On Wed, Jun 4, 2025 at 3:37 PM Kentaro Hara <har...@chromium.org> wrote:

As part of the Onion Soup efforts (2015 - 2018 ish), we tried to minimize platform/wtf and merging things into ::base and ::std. We removed lots of things. I'd not say we are complete but an easy part is already done :)

The remaining ones are: Oilpan-integrated data structures, String/AtomicString-related data structures, Blink-specific data structures.

Thanks! Where in particular do hash_* and ref_counted.h fall in the above?

[Kentaro Hara]

hash_* are Oilpan-integrated. HeapHashSet, HeapHashMap etc.

ref_counted.h is already a thin wrapper of base::RefCounted. We can remove WTF::RefCounted by replacing all the callers.

--

Kentaro Hara, Tokyo

[Dave Tapuska]

We need the WTF types for tracing oilpan objects. I don't think that is ever going to go away. You likely could make STL variants of some of the containers that supported tracing, but that seems like wasted effort.

dave

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAMGE5NFDH1HnUatq1gm7k82CmqZaC-F1L4fJyDsHNKKNrBJq2Q%40mail.gmail.com.

[Michael Lippautz]

On Wed, Jun 4, 2025 at 3:51 PM Dave Tapuska <dtap...@chromium.org> wrote:

We need the WTF types for tracing oilpan objects. I don't think that is ever going to go away. You likely could make STL variants of some of the containers that supported tracing, but that seems like wasted effort.

Concurrent tracing is incompatible with STL as it requires some atomics for internals and hooks that are just not there. 

 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAHgVhZWWoMjTiEjXfN-ihm%2BiWwj_vRFVEC2WhDA3Vxa0ZMwUNQ%40mail.gmail.com.

[Colin Blundell]

Thanks, this is really helpful info!

[Daniel Cheng]

+1 to what's already been said. However:

1. We may want to reconsider some of the callback stuff and how "necessary" it is. Blink has some additional machinery to separate same-thread callbacks and cross-thread callbacks, due to the need for cross-thread copier, but it means we have to reinvent the wheel sometimes, e.g. @Dale Curtis is experiencing this now for base::BindPostTask (and we had to add a lot of abstractions to base::SequenceBound so we could provide WTF::SequenceBound).

2. WTF's hash tables make me a bit sad. The in-place representations for deleted / empty objects regularly surprises people (especially not being able to use 0 as a key by default!), and they have a max load factor of 0.5, which is pretty low compared to most other state of the art hash tables. Fixing the former means storing some more metadata out-of-line though, and I'm not sure if that's compatible with Oilpan's concurrent tracing...

Daniel

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAMGE5NHC1%2BDgmvQCS18jSBckpPZPUt9s%3DFKiGw1P6_Ef7qQ%2BoQ%40mail.gmail.com.

[Steinar H. Gunderson]

On Wed, Jun 04, 2025 at 08:09:55AM -0700, Daniel Cheng wrote:
> 2. WTF's hash tables make me a bit sad. The in-place representations for
> deleted / empty objects regularly surprises people (especially not being
> able to use 0 as a key by default!), and they have a max load factor of
> 0.5, which is pretty low compared to most other state of the art hash
> tables. Fixing the former means storing some more metadata out-of-line
> though, and I'm not sure if that's compatible with Oilpan's concurrent
> tracing...

+1. There's been a _lot_ of activity in C++ hash tables in the blogosphere
over the last ten years (to the point where people have even made meta-posts
comparing them all under various conditions), and it would be very
interesting to see if we could adapt some of them for our use. I'd guess
we're leaving a fair bit of performance on the table; in css/, we made our
own and won a fair bit of CPU/RAM on that. (We can't use it to replace
WTF::HashMap wholesale, unfortunately, in particular because insertion
is allowed to fail in an attack scenario.)

/* Steinar */

[Michael Lippautz]

On Wed, Jun 4, 2025 at 5:10 PM Daniel Cheng <dch...@chromium.org> wrote:

+1 to what's already been said. However:

1. We may want to reconsider some of the callback stuff and how "necessary" it is. Blink has some additional machinery to separate same-thread callbacks and cross-thread callbacks, due to the need for cross-thread copier, but it means we have to reinvent the wheel sometimes, e.g. @Dale Curtis is experiencing this now for base::BindPostTask (and we had to add a lot of abstractions to base::SequenceBound so we could provide WTF::SequenceBound).

2. WTF's hash tables make me a bit sad. The in-place representations for deleted / empty objects regularly surprises people (especially not being able to use 0 as a key by default!), and they have a max load factor of 0.5, which is pretty low compared to most other state of the art hash tables. Fixing the former means storing some more metadata out-of-line though, and I'm not sure if that's compatible with Oilpan's concurrent tracing...

If you have a proposal somewhere we can see what it takes to make it compatible. Happy to brainstorm if someone wants to pick this up.

We have also been bitten by our low load factor and various iterations that showed up in rendering hot paths.