1231501 - (memory-coverage) [meta] Memory Tool Coverage

Status: NEW

(DevTools :: Memory, defect, P5)

Description

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

This is a meta bug to track bugs that increase the subset of the heap that the memory tool and JS::ubi::Node cover and can report on.

Comment 1

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

General STR for looking at the size of the known unknowns of our memory tool for a given tab:

* take a heap snapshot, look at its total size
* open about:memory, take a measurement, find the selected tab, look at its total size

We will always trail about:memory, because we only consider things that are reachable by the GC (or the CC as well, sometime soon in the future) the same way that about:memory is trailing behind DMD which sees all. About:memory will include things that aren't strictly retained and are more of an implementation detail, eg the size of a whole Arena even though only some cells in the arena are live.

However, with that said, the gap between about:memory and heap snapshots is larger than it should be and in general we would like to minimize it to the point where the only difference is from those things that about:memory considers that we will never consider (such as whole Arenas as described above).

Comment 2

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

P5 because it's a meta bug; blockers should have their own accurate priorities.

Comment 3

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Is there an example somewhere of how to do this for a DOM object?

Comment 4

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #3)
> Is there an example somewhere of how to do this for a DOM object?

No examples yet, unfortunately.

You have to implement a specialization of the `JS::ubi::Concrete<T>` traits template for your DOM type:

* JS::ubi::Concrete<T> definition: https://dxr.mozilla.org/mozilla-central/rev/d5d53a3b4e50b94cdf85d20690526e5a00d5b63e/js/public/UbiNode.h#640

* Example concrete specialization for JS::Symbol: https://dxr.mozilla.org/mozilla-central/rev/d5d53a3b4e50b94cdf85d20690526e5a00d5b63e/js/public/UbiNode.h#1037

However, for your new type to show up in our various memory analyses, we _also_ need to be able to reach it when doing traversals. We start from the GC roots (https://dxr.mozilla.org/mozilla-central/rev/d5d53a3b4e50b94cdf85d20690526e5a00d5b63e/js/public/UbiNode.h#929-956), so some `JS::ubi::EdgeRange` returned by the roots or one of the nodes reachable from the roots would need to include an edge with a referent `JS::ubi::Node` that points to your DOM type.

We rely on the GC's tracing infrastructure to discover all of our edges right now, see https://dxr.mozilla.org/mozilla-central/rev/d5d53a3b4e50b94cdf85d20690526e5a00d5b63e/js/src/vm/UbiNode.cpp#217-301,311-322.

The general plan we've had so far is to add another JSClass callback that would provide extra edges for an object being traced (bug 1056992). JS reflectors of C++ DOM objects would then use this to bridge the gap from the JS heap. We also are planning on making some default `JS::ubi::Concrete<T>` specializations for `nsCycleCollectionParticipant` so that we could get a bunch done at once (bug 1057057).