Introduce a wtf/immutable_vector.h ?

[Ian Kilpatrick]

Hey all,

We are at the point where a lot of the vectors within Blink are immutable, (after creation they aren't modified).

(I can provide examples if people are interested, but we have a few in layout, style, and a few other places).

WebKit have "recently" (2021) introduced a FixedVector.h which does this (technically not immutable as contents can be mutated, but is fixed in size).

See: https://searchfox.org/wubkat/source/Source/WTF/wtf/FixedVector.h

I don't have time at the moment to explore this, but it might be worthwhile considering if someone is interested or has time.

The primary benefit is that it can reduce the size of a Vector from 16 bytes (on 64bit) to potentially 4 bytes (if pointer compression is used on the buffer).

(There might be a marginal benefit to placing the size_ member on the actual object instead of in the heap for performance which would raise it to 8 bytes with pointer compression).

The main downside is obviously code maintenance - but likely not too much overhead compared to what already exists.

Any thoughts? (or anyone willing to spend some cycles investigating?)

Ian

[Jeremy Roman]

base::HeapArray is more or less this, except that it lacks support for Oilpan and other Blink-specific things at present.

--
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/CAJL3UpTet7VtZAVUbL723ChjVHFu1can1anY12-HGT91YNs--w%40mail.gmail.com.

[Michael Lippautz]

On Fri, Jan 9, 2026 at 12:24 AM Jeremy Roman <jbr...@chromium.org> wrote:

base::HeapArray is more or less this, except that it lacks support for Oilpan and other Blink-specific things at present.

Unfortunately, types in base are often really hard to specialize for Oilpan wrt to concurrent marking and write barriers. This would probably need to go into WTF.

 

On Thu, Jan 8, 2026 at 5:38 PM Ian Kilpatrick <ikilp...@chromium.org> wrote:

Hey all,

We are at the point where a lot of the vectors within Blink are immutable, (after creation they aren't modified).

I am curious here: When you say "after creation", how are these vectors constructed? Specifically for Oilpan, there's actually quite some benefits to try to construct them via constructors and initializers. I guess this is the case as a FixedVector would also only offer the same capabilities?

 

(I can provide examples if people are interested, but we have a few in layout, style, and a few other places).

WebKit have "recently" (2021) introduced a FixedVector.h which does this (technically not immutable as contents can be mutated, but is fixed in size).

See: https://searchfox.org/wubkat/source/Source/WTF/wtf/FixedVector.h

I don't have time at the moment to explore this, but it might be worthwhile considering if someone is interested or has time.

The primary benefit is that it can reduce the size of a Vector from 16 bytes (on 64bit) to potentially 4 bytes (if pointer compression is used on the buffer).

(There might be a marginal benefit to placing the size_ member on the actual object instead of in the heap for performance which would raise it to 8 bytes with pointer compression).

The main downside is obviously code maintenance - but likely not too much overhead compared to what already exists.

Any thoughts? (or anyone willing to spend some cycles investigating?)

 

Ian

--
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/CAJL3UpTet7VtZAVUbL723ChjVHFu1can1anY12-HGT91YNs--w%40mail.gmail.com.

--
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/CACuR13dt1L1gjbdUDDVFKeV0%3D_ezWP8QJjuN7pJqJSZ%2B%3DpQQTA%40mail.gmail.com.

[Ian Kilpatrick]

On Fri, Jan 9, 2026 at 12:00 AM Michael Lippautz <mlip...@chromium.org> wrote:

On Fri, Jan 9, 2026 at 12:24 AM Jeremy Roman <jbr...@chromium.org> wrote:

base::HeapArray is more or less this, except that it lacks support for Oilpan and other Blink-specific things at present.

Unfortunately, types in base are often really hard to specialize for Oilpan wrt to concurrent marking and write barriers. This would probably need to go into WTF.

 

Right -  most of the work here would be integration with Oilpan (and don't forget making it compactable, clang gc-plugin safety, etc) :).

 

On Thu, Jan 8, 2026 at 5:38 PM Ian Kilpatrick <ikilp...@chromium.org> wrote:

Hey all,

We are at the point where a lot of the vectors within Blink are immutable, (after creation they aren't modified).

I am curious here: When you say "after creation", how are these vectors constructed? Specifically for Oilpan, there's actually quite some benefits to try to construct them via constructors and initializers. I guess this is the case as a FixedVector would also only offer the same capabilities?

At the moment most of them are just built up with ReserveInitialCapacity + emplace_back/push_back.

WebKit's FixedVector uses a createWithSizeFromGenerator which would be a relatively straight forward re-write for most of our usages to if we wanted to push them into the constructor.