Code resident set size is a murky metric that we don't really report currently. Here are several ways we try to approximate it:

1. Calling mincore() on the range of native code
2. Reporting SUM(PSS(code) for all chrome processes)


Issues with these:
==================

1. mincore()
------------

mincore() will report that a page is "in core" if accessing it would not cause a major page fault. This means that unless there is memory pressure, the native library prefetch that we do will make it report that everything is in core. Similarly, the numbers will be affected by other processes running on the system (for instance WebView, when using Monochrome). This is actually visible on the LibraryLoader.PercentageOfResidentCodeBeforePrefetch.ColdStartup UMA histogram.

2. SUM(PSS)
-----------

PSS only sums up to RSS when taking all the processes sharing a given page into account. Since we can only look at Chrome's processes, the resulting number is an underestimate in the presence of other processes sharing the same pages, such as WebView with monochrome. In addition, collecting the numbers requires parsing /proc/self/smaps, which is quite costly.


To sum it up, mincore() will overstimate memory usage, and PSS will underestimate it.


Proposal
========

We know the virtual address range of executable code in each process, using the anchor symbols declared in anchor_functions.h. These are guaranteed to be correct (except for component builds) since they are generated via a linker script.

Parsing /proc/self/pagemap in the matching range tells us whether a page is mapped in a given process. Taking the union of all the mapped page sets in all Chrome processes gives us a picture of code RSS which is unaffected by prefetch and WebView.

/proc/self/pagemap doesn't necessarily contain the page frame numbers depending on the kernel, but the only relevant info in this case is the offset relative to the start of the executable code range, which we know in each process, so we don't need the physical addresses to compute the overall footprint.

The rough sketch is then:
- In each process, open and parse /proc/self/pagemap and collect the set of mapped code pages
- Send these over IPC/Mojo to the browser process, merge the sets, then compute the metric.

In terms of cost, this would require, per process:
- 3 syscalls (open(), read(), close()) provided that we can allocate 8 bytes per page (~80kB per process)
- 1 bit per page for the bitfield
- 1 IPC to the browser process

This relies on the assumption that we can read /proc/self/pagemap, which needs to be checked.