We should add a 'global' field to JSScript, and change JS_ExecuteScript to clone JSScript objects if necessary to match the global object passed. This is needed to allow us to enumerate all the scripts in use by a particular global object, along with several other current SpiderMonkey goals; see bug 563375, comment 4. We can accomplish this by having JS_ExecuteScript use copies of JSScripts owned by globals other than the one passed to it.

This should not be done unconditionally. It won't show up in SunSpider but it will slow down all our currently shared (even precompiled and fastloaded) XUL scripts. The plan dvander and I last discussed was for those not-compile-and-go scripts to remain immutable and global-free. /be

Do we have metering for XUL script sharing? IIRC it doesn't help in the dominant single-window case, and where we have multiple windows we probably want to respecialize for each window so we get maximum perf, right?

(In reply to comment #1) > This should not be done unconditionally. It won't show up in SunSpider but it > will slow down all our currently shared (even precompiled and fastloaded) XUL > scripts. The plan dvander and I last discussed was for those not-compile-and-go > scripts to remain immutable and global-free. For JIT purposes, I think we just need to classify each script as either single-global, known at compile time; or multiple global, given at execute time. We would want all content scripts to be single-global. For the purpose of enumerating scripts that are in use by a given global, would it work to attach a list of globals to each script that have been used to run it (or is currently being used to run it? not sure).

nsXULPrototypeCache.cpp is what it is -- meter-free at a glance unless the mScriptTable (a nsDataHashtable<nsURIHashKey,CacheScriptEntry>) has metering at its level. It may be something we can measure and find acceptable, but my spider sense is tingling. We're talking potentially quite a lot of scripts, and not just for XUL windows -- JS components too (startup time). On its face, cloning a script every time JS_ExecuteScript is called is bound to hurt performance for small scripts enough that it shouldn't be done always. There's simply no need to enumerate scripts for a global in many embeddings, or really in the absence of a debugger. Another point is that JSScript sharing by hashing and caching (ccache(1)-style) is on our radar -- bug 288473. Jorendorff had mentioned two kinds of scripts, distinct types. Function has-a script but that type could be different from the global-pinned script type. So JSScript would be the kind used for unoptimized, cacheable global code and (as today) for interpreted functions, and JSGlobalScript or some such for this bug's purpose. But dvander has been working on optimizing compile-n-go functions to use global specific bytecodes too, IIRC. So then function would need to use either kind of type, if we do make a C++ type distinction. /be

It seems to me that making scripts per-compartment gives us what we really wanted from this bug anyway. Enumerating the scripts in a compartment should be fine for our purposes.