Large read-only shared mappings can be unnecessarily expensive

Firefox stackwalking code reads a lot of symbol information by walking /proc/.../maps, mapping the entirety of every file it finds MAP_SHARED and PROT_READ, processing symbol data, and then unmapping the file. One of these files is libxul.so which is 800MB (including debug info!) on my system. During recording we copy all that data into the trace. Then during replay finish_shared_mmap creates an EmuFs entry and copies that data into a temporary EmuFs file. Even worse, the processing takes quite a long time and happens off the main thread, so during debugging a number of session clones are created --- each on of which makes its own copy of all that data. On one replay run I see 11 copies of libxul.so being created in /dev/shm, at which point it fills up and we can't replay any more... This is all entirely pointless since libxul.so does not change during the recorded run!

A number of other r--s mappings occur persistently in Firefox --- fontconfig cache, mime.cache, gconf-modules.cache. So if we can detect shared mappings that never change and reduce the cost of them, that would really help.

Start by tracing how Firefox shared read-only mappings are recorded and how finish_shared_mmap creates temporary EmuFs files during replay. Measure the repeated libxul.so copies and define done as reducing redundant storage and processing for mappings that do not change during recording, without breaking replay.