Closed
Bug 567198
Opened 14 years ago
Closed 13 years ago
Implement JS_CopyScript JSAPI function
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 584789
People
(Reporter: jimb, Assigned: jimb)
References
(Blocks 1 open bug)
Details
Implement, document, and test a function that makes a fresh, deep copy of a JSScript object, suitable for execution in a thread or global object different than the original JSScript. For various reasons, SpiderMonkey is moving towards restricting each JSScript to be used with a single global object. Before we can impose this requirement, we must make it possible for embedders to comply with it by providing a function which copies a JSScript object.
Assignee | ||
Updated•14 years ago
|
Assignee: nobody → general
Component: JavaScript Debugging APIs → JavaScript Engine
QA Contact: jsd → general
Comment 1•14 years ago
|
||
See WrapEscapingClosure in jsfun.cpp, which was done under pressure but really wants a script->clone() method. /be
Comment 2•14 years ago
|
||
Comment 0 says a script per global but this would hurt Txul and other XUL script sensitive perf tests. We really want both shared, less-optimized, immutable scripts as we (can) have today, and derived scripts -- as well as freshly compiled without making any immutable less-optimized script -- that are optimized for their one and only global. /be
Comment 3•14 years ago
|
||
Last thought: internally we have Clone APIs (want C++ clone methods, will get there by incremental cleanup). The general clone-an-object case is hard. But it may be worth thinking about it a bit since AFAICT we'll have script, function, and regexp cloning. Making scripts GC'ed could come up too, to fix the old mandatory New/Destroy API usability issues, particularly with respect to rooting (you can really only keep the script's atoms safe by wrapping it in a script object, which hands off the lifetime to the object, so you don't call JS_DestroyScript -- we could change to always do this, or even make JSScript a GC-thing that doesn't need an object, and then JS_DestroyScript could be advisory, or a no-op). /be
Assignee | ||
Updated•14 years ago
|
Assignee: general → jim
Comment 4•14 years ago
|
||
Bug 584789 is implementing most of this, but probably not thread-safety as mentioned in comment 0.
Assignee | ||
Comment 5•13 years ago
|
||
I think bug 584789 and the compartments work has done what was really needed here.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Updated•13 years ago
|
Resolution: WORKSFORME → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•