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
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)?
(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.
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
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.
You need to log in before you can comment on or make changes to this bug.