Going to keep this bug Pri-3 for now. Main goal is to record conversation between asvitkine@ and myself on tradeoffs for file-backed vs memory-backed histograms.

We currently use file-backed histograms for metrics in the browser process. According to this UMA histogram:
https://uma.googleplex.com/p/chrome/histograms/?endDate=20180919&dayCount=1&histograms=UMA.PersistentAllocator.BrowserMetrics.UsedPct&fixupData=true&showMax=true&filters=platform%2Ceq%2CW%2Cchannel%2Ceq%2C4%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial

99% of users have <27% usage of the 8MB file, so <2MB. 

Benefits of file backed:
Allows us to get histograms for unclean shutdowns of Chrome. On Windows stable channel, that's 7.1% of all exits.

Drawbacks:
Causes synchronous IO for the caller anytime the page is not in the page cache. This means there's a startup cost when first paging in the file. Also, if the device is under machine pressure and the page is evicted, then the cost will have to be paid again, possibly on the UI/IO threads.

This has highest impact on users with spinning disks + low amounts of memory.

Comparison to memory backed:
Under memory pressure, memory-backed pages will be compressed [before being swapped]. Filed-backed pages will not be compressed, so will always pay the swap cost.

Aside on eviction patterns:
The impact of file-backed histograms depends quite a bit on eviction heuristics of the OS. On Linux, code pages are never evicted but file-backed pages are. Android recently implemented eviction of code pages. Not sure about Windows/macOS.

Action item:
Current plan is to wait for resolution of https://bugs.chromium.org/p/chromium/issues/detail?id=882892. Then we can use slow reports/SSM to understand rough impact of steady-state histogram usage with filed-backed pages. 

One tricky bit is that the cost will be born across all histogram accesses, so those will need to be aggregated to measure full impact.