791853 - Add memory reporters for self-hosted JS

Status: NEW

(Core :: JavaScript Engine, defect)

Description

[Till Schneidereit [:till]]

Once we have a meaningful amount of self-hosted code, seeing its memory use in a way that's not mixed with that of client JS code might become helpful for debugging purposes.

I think this entails two tasks:
- tracking memory usage of the global that self-hosted code gets compiled into
- tracking memory usage of self-hosted functions as they're lazily cloned into the globals they're used in

Comment 1

[Nicholas Nethercote [inactive]]

If self-hosted code gets put into its own global, then it'll get a corresponding compartment, and therefore it will show up separately in about:memory, right?

Or is the problem that these self-hosted compartments will be intermingled with client code compartments (e.g. multiple compartments under a "window()" sub-tree)?

Comment 2

[Till Schneidereit [:till]]

(In reply to Nicholas Nethercote [:njn] from comment #1)
> If self-hosted code gets put into its own global, then it'll get a
> corresponding compartment, and therefore it will show up separately in
> about:memory, right?

That should happen, yes. Unfortunately it doesn't seem to do so, however. Is there anything special that's being done to register compartments with about:memory apart from using JS_NewGlobalObject?

For reference, the self-hosting is initialized in JSRuntime::initSelfHosting upon creation of the runtime's first context.

> 
> Or is the problem that these self-hosted compartments will be intermingled
> with client code compartments (e.g. multiple compartments under a "window()"
> sub-tree)?

To actually use self-hosted functions, we have to clone them into the globals using them. This happens, lazily on first use, in JSRuntime::cloneSelfHostedValueById. Maybe we can set a flag in the target compartment that makes it report memory differently and reset it after cloning?

That wouldn't deal with memory used for TI and JIT code of self-hosted functions, however.

Comment 3

[Till Schneidereit [:till]]

More info from IRC:

self-hosting global:
njn
what is the principals of that compartment?  because that's the name used for it
till
njn: let me check
till
njn: ah, that explains it: principals is set to NULL
njn
till: right;  look at GetCompartmentName() in js/xpconnect/src/XPCJSRuntime.cpp
njn
short story is that it'll be called "null-principal"
njn
till: it's possible to give it a more descriptive name
njn
till: hmm, but that might only be possible in xpconnect

cloned self-hosted functions:
njn
till: maybe.  are these cloned functions marked in some way as having been cloned?
till
njn: they are marked as being self-hosted functions
till
njn: specifically, they have the flag JSFUN_SELF_HOSTED set
njn
till: ok, you can report them separately.  See StatsCellCallback() in jsmemorymetrics.cpp -- that's where functions and scripts are measured
njn
till: you could add a new field to CompartmentStats
02:57 njn
till: it might be worth doing, even if it doesn't end up being committed, just for your own info

Comment 4

[Nicholas Nethercote [inactive]]

To summarize our discussion on IRC:  the compartment in which self-hosted functions are created gets its name from its principals, which is currently NULL, and so it's called "null-principal" in about:memory.

As for compartment into which the functions are cloned, it is possible to report cloned self-hosted functions separately from "normal" functions, because they are marked as being cloned.