How fragmented is the memory they use? Is that a bunch of collection of biggish objects or a forest of smaller objects retaining each other?
If the former, ack.
If the latter a MDP might be overkill as that will require using some sort of invasive memory estimation which then we'll have trouble using in !local_debugging purposes because will be slow.

Let's look at a trace from one of our EM stories, where frame_navigation_entry.cc allocates 2.5MiB: go/onqby (go/kujpx for a trace).

In that trace WebContentsImpl::UpdateStateForFrame() calls FrameNavigationEntry::SetPageState() 61 times and allocates 1,599.4 KiB.

Also NavigationEntryImpl::AddOrUpdateFrameEntry() causes 967.5 KiB of allocations:

1. FrameNavigationEntry::FrameNavigationEntry() allocates 579.9 KiB in 66 allocations

2. FrameNavigationEntry::SetPageState() allocates 383.8 KiB in 6 (!!) allocations

See also  crbug.com/626202#c38 

In general PageState is an object that contains a bunch of state that is used for restoring when navigating back/forward or during session restore. It contains things such as scroll offset, frame name (which is where we are seeing a hit in memory), the URL of the page, etc. When it is sent to the browser process, it is serialized into a contiguous buffer and stored on NavigationEntry/FrameNavigationEntry. It is also written to disk for session restore purposes.

Is there a good primer on what MDP is and how hard it is to write one? Beyond PageState, I think most of the session history code is not easily influenced by content in the renderer process, but might be interesting to see if surfacing more detailed information is needed.

I don't know if there is a document about implementing MDPs (Primiano?), so I'll just dump everything I know.

MemoryDumpProvider (base/trace_event/memory_dump_provider.h) is a simple interface with a single virtual method, OnMemoryDump(). In that method you create dumps with path-like names (foo/bar/baz) and they end up showing in the UI hierarchically ("foo" will be in Overview pane, clicking on it will reveal foo/bar/baz values). Note that you need to trace with memory-infra category to see that.

See DOMStorageContextImpl::OnMemoryDump() for a good example. Note that it:

1. Dumps sizes (MemoryAllocatorDump::kNameSize)
2. Dump counts (MemoryAllocatorDump::kUnitsObjects)
3. Adds custom columns (beyond kNameSize and kNameObjectCount)

You register MDPs in memory-infra via MemoryDumpManager::RegisterDumpProvider() (typically when object is created) and you unregister it via MemoryDumpManager::UnregisterDumpProvider() (typically when object is destroyed).

When registering, you can either specify a task runner, in which case OnMemoryDump() will be called from that runner, or you can pass nullptr, and OnMemoryDump() will be called from arbitrary thread (i.e. you'll likely need to synchronize manually).

There are lots of other small details (which can be ironed out during codereview), but hopefully this will help to get you started.


BTW, in the latest run of EM stories frame_navigation_entry.cc allocated 5.8 MiB (go/fxbus) - comparable to all other parts of Chrome combined.

> I don't know if there is a document about implementing MDPs (Primiano?)
https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/adding_memory_infra_tracing.md

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot