During replay, files are mmapped.
As long as any worker is reading from a given file, the contained (immutable) data will be available in memory.
OpMsgRequest is constructable from a Message. Message holds a SharedBuffer and has non-const methods which would attempt to mutate the buffer. SharedBuffer takes an allocator type parameter (i.e., changing the allocator requires plumbing a type parameter everywhere relevant, and leads to an "incompatible" type - it is not a type erased allocator).

However, OpMsg::parse, used in constructing OpMsgRequest only requires const access to a Message - it does not logically need owned/mutable data, it's just the existing interface leads to this.

Many OpMsg static methods have the following pattern:

uint32_t OpMsg::flags(const Message& message) {
    if (message.operation() != dbMsg)
        return 0;  // Other command protocols are the same as no flags set.

    return BufReader(message.singleData().data(), message.dataSize())
        .read<LittleEndian<uint32_t>>();
}

That is, only const accesses (and read access to the underlying data) is required.

This could be refactored such that OpMsg can be parsed from a "view" type (which Message could be implicitly converted to, and can use internally to avoid duplicating methods).