These are no longer used after the removal of XBL. The underlying
SpiderMonkey APIs will be removed as well to fascilitate modernizing of
bytecode caching.
Differential Revision: https://phabricator.services.mozilla.com/D54007
--HG--
extra : moz-landing-system : lando
JSClass contained void* members corresponding to the internal pointer members of js::Class. This stores the internal members in JSClass and removes js::Class.
This leaves js::Class aliased to JSClass while we remove references to it. I also aliased Jsvalify and Valueify into global scope temporarily to make this compile. These get removed in the following patches.
I had to remove a few functions which now don't compile with js::Class being the same type as JSClass.
Differential Revision: https://phabricator.services.mozilla.com/D41983
--HG--
extra : moz-landing-system : lando
Using process-wide prefs is consistent with the other JIT options and is simpler
to work with (one place to initialize for all runtimes).
Differential Revision: https://phabricator.services.mozilla.com/D37385
--HG--
extra : moz-landing-system : lando
This makes it more obvious that it is an XPIDL interface.
I also changed a RefPtr<> to an nsCOMPtr<>.
Differential Revision: https://phabricator.services.mozilla.com/D28235
--HG--
extra : moz-landing-system : lando
This is needed to test the test harness's handling of a negative leak
being reported by the XPCOM leak checker.
Depends on D17535
Differential Revision: https://phabricator.services.mozilla.com/D17536
--HG--
extra : moz-landing-system : lando
In order to test the test harness's handling of a process failing to
produce a leak log, add a special function that disables the bloat log
output.
Differential Revision: https://phabricator.services.mozilla.com/D17534
--HG--
extra : moz-landing-system : lando
Reasons for doing this:
* nsXPCWrappedJS has complicated GC behavior and we're seeing some oranges in this area.
* Due to the GC/CC complexity, the global stored in nsXPCWrappedJS *must be* the
object's global in the root-wrapper (implies non-CCW) case. If we do that, the
global is redundant because we can just get it from the object when we need it.
* For the CCW case, it probably doesn't matter too much which chrome global we
use so we can use the compartment's first global - we now have an API for that.
This may also save some memory because it avoids keeping globals alive unnecessarily
and matches what we do for WrappedNatives and CCWs now. Furthermore, bug 1478359
comment 12 suggests CCWs can only show up here for in-content XBL and that's in the
process of being removed.
Differential Revision: https://phabricator.services.mozilla.com/D15096
--HG--
extra : moz-landing-system : lando
This is a complete rewrite of the interface while maintaining the same APIs.
Each ID is fully-contained within a single object, does not require a finalizer,
and is cheap to create.
Beyond using reserved slots, this code avoids using custom ClassOps, instead
preferring Symbol.hasInstance and eager constants.
One major change which occurred in this patch was the move from storing a nsCID
to storing the ContractID for JSCID objects. This eliminates the need for the
'refreshCID' method, and hopefully shouldn't have performance implications.
If we discover that there are performance problems there, we can look into
stashing the CID, and re-introduce 'refreshCID', despite its surprising
behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D2286
These two interfaces are effectively never used, so to avoid needing to support
ClassID2JSValue with the new implementation, I remove them entirely.
Differential Revision: https://phabricator.services.mozilla.com/D2285
This lets us get rid of the method 'initalize', which currently needs the
internal representation of JSCID.
This particular method is removed entirely in Part 9, and only exists to keep
intermediate states building & running.
Differential Revision: https://phabricator.services.mozilla.com/D2282
This should be mostly compatible with the original implementation. I tried to
simplify things here to just directly wrap and use JS objects, calling methods
on them. This eliminates the nsXPCConstructor type completely, replacing it with
a JSNative constructor with predefined READONLY | PERMANENT properties.
Differential Revision: https://phabricator.services.mozilla.com/D2280
This interface is only used for a few testing functions. Just move
them to Cu.
Differential Revision: https://phabricator.services.mozilla.com/D8168
--HG--
extra : moz-landing-system : lando
This interface is only used for a few testing functions. Just move
them to Cu.
Differential Revision: https://phabricator.services.mozilla.com/D8168
--HG--
extra : moz-landing-system : lando
This method does very little, and is called in only a few places, so
just inline it. The error variant is not called at all. Simplifying
this makes it easier for me to change do_QueryInterface.
Differential Revision: https://phabricator.services.mozilla.com/D7527
--HG--
extra : moz-landing-system : lando