Closed Bug 567198 Opened 14 years ago Closed 13 years ago

Implement JS_CopyScript JSAPI function

Categories

(Core :: JavaScript Engine, defect)

x86
Linux
defect
Not set
normal

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: nobody → general
Component: JavaScript Debugging APIs → JavaScript Engine
QA Contact: jsd → general
See WrapEscapingClosure in jsfun.cpp, which was done under pressure but really wants a script->clone() method.

/be
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
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: general → jim
Depends on: 438633
Blocks: 584789
No longer blocks: 584789
Bug 584789 is implementing most of this, but probably not thread-safety as mentioned in comment 0.
I think bug 584789 and the compartments work has done what was really needed here.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
Resolution: WORKSFORME → DUPLICATE
You need to log in before you can comment on or make changes to this bug.