Subj : Re: Memory growth problem To : Mike McIntosh From : Brendan Eich Date : Sat May 17 2003 04:03 pm Brendan Eich wrote: > I did want to get back to you on the scope object usage above. It seems > fine, although there is a potential for unwanted sharing and security > domain violation in the shared m_glob prototype. An option that avoids > those hazards is to use JS_ResolveStandardClass from your > global_class.resolve hook, and JS_EnumerateStandardClasses from > .enumerate -- then you don't need the m_glob prototype with its standard > classes, and each scope object gets only those standard objects that it > actually uses. > > If you prefer to stick with the shared prototype, you'll want to use the > new JS_SealObject(cx, m_glob, JS_TRUE) API on m_glob after you've called > JS_InitStandardClasses on it, but before it is otherwise used. So the punchline on sharing a superglobal (via the proto slot) among N global objects, vs. using lazy standard class resolution, is this: - If all scripts scoped by globals in the superglobal case can trust one another not to decorate, e.g., String.prototype, with evil or simply incompatible methods and properties, then sharing an unsealed superglobal is simplest and uses the least amount of memory. - Else if scripts do not need, and never will need, to set properties on standard objects such as String.prototype, use a sealed superglobal. This doesn't give script authors the full power specified by ECMA-262 -- they can't add a String.prototype.subst method, for example, to do some new kind of substitution, where the method is available on all strings once the proto-property has been set. - Else scripts must need their own ECMA-262-specified global objects, apparently complete with their own standard class objects that they can decorate without collisions or security holes. In this case, use lazy standard class resolution (JS_ResolveStandardClass from a global_resolve hook, etc. -- see js.c for an example). /be .