1802907 - [meta] Migrate to `std::` equivalent when it makes sense

Status: NEW

(Core :: MFBT, enhancement)

Comment 1

[Andrew McCreight [:mccr8]]

I think this is a good thing to do in general, but please exercise particular caution when it comes to the container data structures, like std::vector.

• std containers at least at one point were using poor growth factors, which can lead to a lot of internal fragmentation. See this Facebook writeup from a number of years ago. We have spent at least a little bit of time time tuning the growth strategies of XPCOM data structures (eg bug 1048044), at least somewhat tuning things towards the specific internal implementation details of the version of jemalloc we are using.
• std containers can have API requirements we don't need that lead to poor memory usage. For instance, a std::queue with a single element in it can have a thousand entries in it, because it is required to support stable interior pointers.
• We seem to use a different STL implementation on every one of our platforms, and some are fairly new and others are quite old, so it is possible that a container could have memory characteristics that are good on Windows and poor on Android, and there's no way to figure it out without testing on each platform.
• std containers don't support memory reporting. As seen above, containers can end up with a lot of internal fragmentation, so to truly understand their memory usage it is important to be able to get a pointer to every block of memory in a container to pass to the allocator, but this isn't a capability that the STL provides. You could hack up something unsafe for local experimentation, but we wouldn't be able to ship that to users, and memory reports from users can be very useful.

Comment 2

[Andrew McCreight [:mccr8]]

Another important one I forgot:

• Many of our XPCOM/MFBT containers like nsTArray have release mode bounds checking, which is important for Firefox security. While the STL implementations are implementing various hardening options, the fact that we ship a variety of STL implementations with a wide range of ages means it will likely take a lot of time and effort to get stl containers to the level of hardening as our own home grown data structures. I filed bug 1986488 about this problem but it doesn't seem like we'll be able to fix it soon. Not all of our own data structures are hardened like this, but at least we have the ability to add release checking if it seems like a problem.