This is complementary to bug 1262671 and bug 1235633. It is good to avoid copies and allocation of large blocks at the IPC layer, but there are a few consumers, like StructuredCloneData, that send data across IPC encoded as giant strings. When they deserialize, they end up creating a gigantic string, which can likely lead to memory problems. It would be good if there was a Pickle API that worked better in this situation. The simplest thing would be to return a SegmentedVector, so that these messages didn't require as much contiguous address space. A better solution would be to extend the approach of bug 1235633 and allow these users to use the same underlying storage as the Pickle(), so that we would avoid the copy, but entangling the lifetimes of different layers like this may be tricky, and could lead to other memory issues. (For instance, if a 10 character string ends up keeping alive a very large message.)

Can this be done with a Move()? Or do we really need both layers to have access to the data at the same time?

I think a better approach here is to add ParamTraits overloads to transfer data directly into or out of the Message, without the string intermediary. That will have to be done on a case-by-case basis, so I'll close this and file bugs for those as appropriate.