Hi,
When you load about:memory, all the memory reporters run. Each
measurement made includes a description, which shows up in
about:memory as a tool-tip if you hover over the measurement.
These descriptions are string literals in C++ code, and they can be
long (e.g. several sentences). They mostly get passed from C++ to a
JS callback within aboutMemory.js via this XPCOM interface:
[scriptable, function, uuid(5b15f3fa-ba15-443c-8337-7770f5f0ce5d)]
interface nsIMemoryMultiReporterCallback : nsISupports
{
void callback(in ACString process, in AUTF8String path, in int32_t kind,
in int32_t units, in int64_t amount,
in AUTF8String description, in nsISupports closure);
};
|description| is the relevant parameter.
The problem is that the same literal string can be passed to the
callback many times, e.g. once per JS compartment, and it gets
inflated and duplicated each time. So we end up with stuff like this:
│ │ │ ├─────689,568 B (00.17%) -- string(length=346, copies=653,
"Memory allocated to hold headers for copies of the given notable
string. A string is notable if all of its copies together use more
than 8192 bytes total of JS GC heap and malloc heap memory./n/nThese
headers may contain the string data itself, if the string is short
enough. If so, the string won't have any memory reported under
'string-chars'.")
That's an entry from about:memory, measuring 653 duplicates of a
description string. And we can have lots of cases like this. So the
reporting of memory is perturbing subsequent measurements.
Is there a way to avoid these duplications? I have some vague ideas
that I'm not sure are feasible.
- Turn the string literal into a JSAtom on the C++ side and then
somehow pass that over to JS.
- Somehow indicate that I want the string on the JS side to be an
JSExternalString.
- Do a poor man's atom table in nsMemoryReporterManager just for these
descriptions, and install each description on the C++ side, pass some
kind of representative token (e.g. the hash value) through |callback|,
and then extract the string on the JS side... I'm pretty sure that
could be made to work, but it would be ugly.
All suggestions welcome. Thanks!
Nick
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
