This imports the changes from wheezy-lts (http://deb.freexian.com/extended-lts/)
and creates a package we install in the debian7-based images (with a
modified version number to work around bug #1419577.
This leaves out debian7-raw and debian7-packages as unpatched, because
of the chicken-and-egg problem.
Depends on D26100
Differential Revision: https://phabricator.services.mozilla.com/D26102
--HG--
extra : moz-landing-system : lando
When docker images use setup_packages.sh, they add apt sources. While we
currently do run apt-get update to pick those new sources, if a package
provided by them is already installed and not explicitly listed in
subsequent apt-get install, they're not going to be upgraded.
Differential Revision: https://phabricator.services.mozilla.com/D26100
--HG--
extra : moz-landing-system : lando
nsXPCWrappedJSClass now only adds indirections and dynamic
allocations, so eliminate it. The class is kept around as a collection
of static helper functions to avoid needing to move around all of this
code and messing with history. In total, these patches save around 2kb
of dynamic allocations per process.
The major parts of this patch are:
* Dropping indirection for accessing things on nsXPTInterfaceInfo and
renaming things from class to info.
* Removing the stuff related to instances of nsXPCWrappedJSClass
existing (ctor, dtor, field, ISupports implementation, getter methods).
* Removing IID2WrappedJSClassMap, because we only need the map from IIDs
to info.
I dropped the null check in TraverseNative because mInfo is never
cleared, while mClass was.
I dropped the forward declaration of nsXPCWrappedJSClass because no
instances of that class exist, so no function will take or return a
pointer to one.
Differential Revision: https://phabricator.services.mozilla.com/D26218
--HG--
extra : moz-landing-system : lando
Ultimately, this method is really about dumping XPConnect-ish
information about an nsXPTInterfaceInfo, so change it into a static
method that takes an info directly. This loses logging of the
nsXPCWrappedJSClass's ref count, but that is going away in the next
patch anyways.
Differential Revision: https://phabricator.services.mozilla.com/D26217
--HG--
extra : moz-landing-system : lando
This interface serves no real purpose, aside from some weird XPConnect
debugging function. If you are in a debugger already, you can just
call the nsXPCWrappedJSClass DebugDump method directly.
For now, I changed nsXPCWrappedJSClass to just implement nsISupports,
but this will go away later.
I also devirtualized DebugDump(), because it is no longer an XPCOM
method.
Differential Revision: https://phabricator.services.mozilla.com/D26216
--HG--
extra : moz-landing-system : lando
The first idea here is that |this| is actually the GetClass() of the
|wrapper| argument (the one call site looks like
"GetClass()->CallMethod(this, ...)"), so we can locally reconstruct it
when CallMethod is a static method.
The second idea here is that the only real use of the
nsXPCWrappedJSClass is to grab some data from the nsXPTInterfaceInfo
in a few places. This means that we can take a pointer to the info
early on in the function and use that rather than go through the
nsXPCWrappedJSClass. This in turn means that because the info is
statically allocated we no longer need to do a kungFuDeathGrip on the
wrapper's nsXPCWrappedJSClass.
Differential Revision: https://phabricator.services.mozilla.com/D26215
--HG--
extra : moz-landing-system : lando
There are a number of nsXPCWrappedJSClass methods that don't use any
data from |this|, so go ahead and make them static. This is one step
towards eliminating nsXPCWrappedJSClass entirely.
In addition, devirtualize a few methods, because they are going to
have to get devirtualized anyways, and there's no need for them to be
virtual.
Differential Revision: https://phabricator.services.mozilla.com/D26214
--HG--
extra : moz-landing-system : lando
Except retrieving from weak reference, `nsIFrame` should treat
`mozilla::PresShell` directly rather than via `nsIPresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D26388
--HG--
extra : moz-landing-system : lando
We always pass in the platform formated as an update platform. Since the only
variation in formats is between major platforms, be liberal in parsing
platforms, when selecting which unpack logic to use. This makes win64-aarch64
support fall out automatically.
Differential Revision: https://phabricator.services.mozilla.com/D26201
--HG--
extra : moz-landing-system : lando
We only run the cron job on release branches, so it will only get scheduled
there. By not otherwise restricting the job, it makes it easier to test the
cron job on other branches (like try).
Differential Revision: https://phabricator.services.mozilla.com/D26200
--HG--
extra : moz-landing-system : lando
Profiling with DHAT of wasm baseline compiling the Tanks demo shows some
opportunities for reducing the amount of heap allocation, by modestly
increasing the inline-capacity values for a few Vector types.
Compiling the Tanks demo on x86_64-linux, this patch reduces the number of
allocated blocks by around 12000, whilst increasing neither the total
allocated bytes nor the dynamic instruction count.
This field now just caches the IsReflectable() field from the method
info, so get rid of it.
Differential Revision: https://phabricator.services.mozilla.com/D26071
--HG--
extra : moz-landing-system : lando
XPCConvert::IsMethodReflectable() is derived entirely from
nsXPTMethodInfo, so we can compute it at build time and include it in
nsXPTMethodInfo. It is the only use of mNotXPCOM and mHidden, so we
can get rid of those fields at the same time.
This paves the way for getting rid of XPCWrappedJSClass::mDescriptors
in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D26070
--HG--
extra : moz-landing-system : lando
There is only a single XPC JS runtime now, so there's no need to keep a
special pointer around.
Differential Revision: https://phabricator.services.mozilla.com/D26068
--HG--
extra : moz-landing-system : lando
The module is manually registered through the component manager in
the gtest setup anyways.
Differential Revision: https://phabricator.services.mozilla.com/D26063
--HG--
extra : moz-landing-system : lando