Using a simple |const char*| is more memory-efficient than allocating a
JS string. We still have to allocate the JS string for passing things
into JS, but ideally we will be able to move the point of allocation
much closer to where it's actually needed, rather than indiscriminantly
doing it all the time.
Using a simple |const char*| is more memory-efficient than allocating a
JS string. We still have to allocate the JS string for passing things
into JS, but ideally we will be able to move the point of allocation
much closer to where it's actually needed, rather than indiscriminantly
doing it all the time.
Using a simple |const char*| is more memory-efficient than allocating a
JS string. We still have to allocate the JS string for passing things
into JS, but ideally we will be able to move the point of allocation
much closer to where it's actually needed, rather than indiscriminantly
doing it all the time.
nsWrapperCache expects the object it stores to have an ObjectMoved op that will
notify the wrapper cache when the object is moved. SpiderMonkey promises don't
have a way to do this.
The XPCConvert changes are needed to allow code that passes around Promise
objects as nsISupports to continue working instead of ending up with
double-wrapped nsISupports (XPCWrappedNative for an nsISupports XPCWrappedJS)
around the SpiderMonkey Promise.
This patch introduces a fake IDL interface just to get the benefits of
cycle collection for the JS-to-C++ link we now need for PromiseNativeHandler
(because the SpiderMonkey Promise somehow needs to point to the
PromiseNativeHandler). Now in practice a bunch of our PromiseNativeHandlers
are not cycle collected. That kinda freaks me out, but spot-checking a few
suggests they do not in fact leak (either because they don't form cycles or
because the Promise they're observing always settles and then releases them).
Either way, that's a problem that exists with or without this patch...
This is the one part of this set of patches that is actually a substantive change
even without SPIDERMONKEY_PROMISE defined. This is being done because I don't
want to create ResolveInternal/RejectInternal methods on dom::Promise in the
new world.
In practice, the difference between MaybeResolve/Reject and
ResolveInternal/RejectInternal is that the former will do nothing if the
Promise is "resolved" in terms of spec terminology: either settled or locked in
to track another Promise. A resolved but still pending Promise can still get
fulfilled (what we call ResolveInternal) or rejected when the promise it's
tracking settles.
So the difference only matters if PromiseWorkerProxy can be working with a
"resolved" Promise (in which case what it's doing now would settle it, while
what I'm switching to would not). But I don't believe PromiseWorkerProxy ever
points to a "resolved" Promise.
These are basically the minimal changes needed to make PromiseDebugging compile
in the new world. It will NOT function correctly (see the XXX comments); Till
will be fixing it up more in bug 911216 as he transitions the relevant bits in
our devtools to work on top of SpiderMonkey promises.
The idea is to not define a "Promise" property on the global and not generate
any of the methods, since SpiderMonkey will implement all of those, but to keep
some of the conversion to/from JS logic and the IDL parser validation bits that
we have right now. Once we can assume SPIDERMONKEY_PROMISE we can probably
change how the "Promise" identifier is handled by the IDL parser and how the
resulting type is handled by codegen, but for now we're aiming for minimal
changes.
Note that the web platform tests don't actually have quite the behavior they're
expected to per the spec yet. They will get adjusted later on as we add
subclassing support to Promise.resolve and Promise.prototype.then.
Wes Kocher
Till Schneidereit
Nathan Froyd
Kyle Huey
Eddy Bruel
Boris Zbarsky
Nathan Froyd
Jonathan Watt
Andrew McCreight
Paolo Amadini
Jeff Walden
Kaku Kuo
simplyblue
Phil Ringnalda
Tom Tromey
Shu-yu Guo