People only use these methods via Cu, so remove them from this
interface. Also, ban anybody from implementing this interface in JS
(though I can't imagine anybody trying), and eliminate a variant of
mozJSComponentLoader::ImportInto that is never called.
MozReview-Commit-ID: Kok5ksXiK5a
--HG--
extra : rebase_source : ef7237953404fd1b75e8e1118b9fc4e2235ff187
The Chromium IPC histogram code used the StatisticsRecorder object for storage.
This is keyed by histogram name, which doesn't match our storage reality anymore.
Instead we use a name to refer to a set of histogram instances that record data from different processes, as well as separating session and subsession data.
Consequently we need to rewrite this storage, which means StatisticsRecorder is not used anymore.
MozReview-Commit-ID: 1LC7YubpKaD
It is only called in a single place, and can't be called from JS, so
inline it and eliminate it.
MozReview-Commit-ID: DWfyfoO5Zht
--HG--
extra : rebase_source : 8a44719af22a4d8724449d6225f4bdd119d648c8
Also, one unused include of nsIProgrammingLanguage, which is unrelated.
MozReview-Commit-ID: LJf2NSwmaYG
--HG--
extra : rebase_source : 63dfca9185535dbfa695cf2f383d81a14ce423c0
The main reason to not do this would be performance (avoiding the
addref/release), but there are two main mitigating factors:
1) All calls to UnwrapReflectorToISupports that pass in a Web IDL object
already do the addref (and in fact QI). So this only affects the
XPCWrappedNative case.
2) The vast majority of the callers proceed to QI on the pointer anyway, and a
second addref is cheap; it's the first addref after a CC that can be
expensive on a cycle-collected object.
Going through the changes one by one:
* In GlobalObject::GetAsSupports, we do have a change that slightly slows down
precisely in the XPCWrappedNative global case. That's the message managers
and the backstagepass. And this really only affects calls to Web IDL statics
from those globals.
* In UnwrapArgImpl we're talking about a Web IDL method taking an "external
interface" type, and the UnwrapReflectorToISupports call is immediately
followed by QI anyway.
* In UnwrapXPConnectImpl we're talking about the case when we have a
non-WebIDL-object implementation of a Web IDL interface. Again, this is the
message manager globals, for EventTarget. And we have a QI call immediately
after the UnwrapReflectorToISupports.
* In the generated HasInstance hook for EventTarget we will be slightly slower
when the LHS of the instanceof is an XPCWrappedNative. And not much slower,
because again there's an immediate QI.
* In InstallXBLField we're never going to have an XPCWrappedNative as thisObj;
it's always an Element in practice. So this is no more expensive than before.
* In sandbox's GetPrincipalOrSOP we now have an extra addref. But it was
followed by various QIs anyway.
* In XPCConvert::JSValToXPCException we have an extra addref if someone throws
an XPCWrappedNative, which is fairly unlikely; our actual Exception objects
are on Web IDL bindings. Plus we have an immediate QI.
* In xpc::HasInstance we have an extra addred if the LHS of instanceof is an
XPCWrappedNative. But, again, there's an immediated QI after the
UnwrapReflectorToISupports.
* In xpcJSWeakReference::Init we are likely doing an extra addref, but again
immediately followed by QI.
I think it's worth making this change just to remove the footgun and that the
perf impact, if any, is pretty minimal.
Most of these changes are just replacements of GetNativeOfWrapper with
UnwrapReflectorToISupports, which is all it did under the hood.
The other changes are as follows:
* In nsDOMClassInfo, we really care whether we have a window, so we can just
UNWRAP_OBJECT to the Window interface, since Window is always on Web IDL
bindings now. Also, the weird compartment check hasn't been needed ever since
GetNativeOfWrapper stopped returning things off the passed-in object's
prototype chain (Firefox 22, bug 658909).
* The only use of do_QueryWrapper was to get a Window in nsDocument; again we
can UNWRAP_OBJECT.
* In XPCJSRuntime, we again just want to check for a Window, so UNWRAP_OBJECT.
xpcshell has a custom directory provider that is passed in when XPCOM is
initialized. XPCOM holds a reference to this directory provider, and
said reference is not released until XPCOM is shutdown. Unfortunately,
the lifetime of the directory provider was not scoped properly, so it
would actually be destructed prior to shutting down XPCOM, resulting in
a stack use-after-free.
To avoid this problem, we need to move the provider so that its lifetime
outlives the call to both XPCOM init and shutdown.
This patch makes the following changes to the macros.
- Removes PROFILER_LABEL_FUNC. It's only suitable for use in functions outside
classes, due to PROFILER_FUNCTION_NAME not getting class names, and it was
mostly misused.
- Removes PROFILER_FUNCTION_NAME. It's no longer used, and __func__ is
universally available now anyway.
- Combines the first two string literal arguments of PROFILER_LABEL and
PROFILER_LABEL_DYNAMIC into a single argument. There was no good reason for
them to be separate, and it forced a '::' in the label, which isn't always
appropriate. Also, the meaning of the "name_space" argument was interpreted
in an interesting variety of ways.
- Adds an "AUTO_" prefix to PROFILER_LABEL and PROFILER_LABEL_DYNAMIC, to make
it clearer they construct RAII objects rather than just being function calls.
(I myself have screwed up the scoping because of this in the past.)
- Fills in the 'js::ProfileEntry::Category::' qualifier within the macro, so
the caller doesn't need to. This makes a *lot* more of the uses fit onto a
single line.
The patch also makes the following changes to the macro uses (beyond those
required by the changes described above).
- Fixes a bunch of labels that had gotten out of sync with the name of the
class and/or function that encloses them.
- Removes a useless PROFILER_LABEL use within a trivial scope in
EventStateManager::DispatchMouseOrPointerEvent(). It clearly wasn't serving
any useful purpose. It also serves as extra evidence that the AUTO_ prefix is
a good idea.
- Tweaks DecodePool::SyncRunIf{Preferred,Possible} so that the labelling is
done within them, instead of at their callsites, because that's a more
standard way of doing things.
--HG--
extra : rebase_source : 318d1bc6fc1425a94aacbf489dd46e4f83211de4
This patch gives some structure and order to the profiler's API.
It also renames AutoProfilerRegister as AutoProfilerRegisterThread, to match
profiler_register_thread().
This patch reduces the differences between builds where the profiler is enabled
and those where the profiler is disabled. It does this by removing numerous
MOZ_GECKO_PROFILER checks.
These changes have the following consequences.
- Various functions and classes are now defined in all builds, and so can be
used unconditionally: profiler_add_marker(), profiler_set_js_context(),
profiler_clear_js_context(), profiler_get_pseudo_stack(), AutoProfilerLabel.
(They are effectively no-ops in non-profiler builds, of course.)
- The no-op versions of PROFILER_* are now gone. The remaining versions are
almost no-ops when the profiler isn't built.
--HG--
extra : rebase_source : 8fb5e8757600210c2f77865694d25162f0b7698a
Changed the type of argument |targetFilter| of NukeCrossCompartmentWrappers()
from CompartmentFilter to JSCompartment* because it is always a single target
compartment, and we can optimize the iteration not to iterate the outer map.
MozReview-Commit-ID: 7cDCgJI0H9z
--HG--
extra : rebase_source : 4973dfd4c3326bf48b78088979962e425e35030c
While we're here, also align their buckets and give them bug_numbers fields.
To change buckets for GC_MAX_PAUSE_MS we need to rename to _2. Because of
GC_MAX_PAUSE_MS' use as a historical perf metric, we need to leave it in-place
for now.
MozReview-Commit-ID: Cffo3q1pR5E
--HG--
extra : rebase_source : 9843ca718dea8694be8029530a0f8646352c5b37
Changed the type of argument |targetFilter| of NukeCrossCompartmentWrappers()
from CompartmentFilter to JSCompartment* because it is always a single target
compartment, and we can optimize the iteration not to iterate the outer map.
MozReview-Commit-ID: 7cDCgJI0H9z
--HG--
extra : rebase_source : ee9341168a28b5e6f273c512b0562ee4ddc297bc
extra : source : e80197b115673f259293d112da61c8dd9edc121e
Currently, the final slice of an incremental GC only gets a GC_CYCLE_END callback, not a GC_SLICE_END callback. So if you are doing anything that expects to see all of the slices, you will be missing one.
Simplify the setup so that every GC is bracketed with CYCLE_BEGIN/END, and every slice is bracketed with SLICE_BEGIN/END, treating a nonincremental as a GC with a single slice (which it is for everything else.)
--HG--
extra : rebase_source : 8e21300819d517b3e35de14930f53b3ab737a44e
Right now, it is a macro, which causes a warning with clang about
extraneous parentheses. Turning it into a function fixes that and is
also nicer.
MozReview-Commit-ID: KTPA9b6oeUu
--HG--
extra : rebase_source : ae063db5a4b5b14bc4a3a8f64adbbecfc897edd9
The patch makes the following proxy changes:
* The number of slots in ProxyValueArray is now dynamic and depends on the number of reserved slots we get from the Class.
* "Extra slots" was renamed to "Reserved slots" to make this clearer.
* All proxy Classes now have 2 reserved slots, but it should be easy to change that for proxy Classes that need more than 2 slots.
* Proxies now store a pointer to these slots and this means GetReservedSlot and SetReservedSlot can be used on proxies as well. We no longer need GetReservedOrProxyPrivateSlot and SetReservedOrProxyPrivateSlot.
And some changes to make DOM Proxies work with this:
* We now store the C++ object in the first reserved slot (DOM_OBJECT_SLOT) instead of in the proxy's private slot. This is pretty nice because it matches what we do for non-proxy DOM objects.
* We now store the expando in the proxy's private slot so I removed GetDOMProxyExpandoSlot and changed the IC code to get the expando from the private slot instead.
When we just had CycleCollectedJSContext (and no CycleCollectedJSRuntime) a
weird thing happened at shutdown:
1. We would call JS_DestroyContext from ~CycleCollectedJSContext. By that time,
the ~XPCJSContext destructor had already finished.
2. Destroying the context runs a final GC. That GC would call back into various
GC callbacks, such as TraceBlackJS and TraceGrayJS.
3. These callbacks would do a virtual method call:
http://searchfox.org/mozilla-central/rev/876c7dd30586f9c6f9c99ef7444f2d73c7acfe7c/xpcom/base/CycleCollectedJSRuntime.cpp#791
4. Normally this method call would call into
XPCContext::TraceNativeBlackRoots. However, C++ changes the vtable for an
object during destruction. So we would only call CycleCollectedJSContext's
version of TraceNativeBlackRoots, which is empty. So we never traced anything.
When I moved this code into the runtime, we actually do call into
XPCJSRuntime::TraceNativeBlackRoots at that time. So the behavior changed, and
that was causing crashes once I nulled out the TLS as you asked. So I removed
these callbacks for the last GC.
MozReview-Commit-ID: 3do13bjpwQj
This patch keeps a list of all the cooperatively scheduled contexts that are
linked to a runtime. In places where we need to iterate over all contexts (for
GC, specifically), it iterates over the list.
MozReview-Commit-ID: 3pKJX78f2l0
This field assumes there is one XPCJSContext globally (i.e., per nsXPConnect
instance). This patch eliminates the field by using different paths to
reach the context.
MozReview-Commit-ID: FjR6cTZ5QfZ
XPCJSContext::Get() now does a TLS lookup, which is a little more expensive
than looking up a global variable. This patch removes as many of the TLS
lookups as possible.
MozReview-Commit-ID: GsqzJn55Lya
Once we have multiple XPCJSContext's, we may have to figure out which one we're
using with TLS. A later patch tries to remove as many of these TLS lookups
as possible so that performance doesn't suffer.
MozReview-Commit-ID: 50uHpDLZmUH
Change FormatStackDump to return UniqueChars and fix up the users. This
removes a bit more manual memory management.
MozReview-Commit-ID: 60GBgeS4rzg
--HG--
extra : rebase_source : 15060321f567816ca434cdf1ef816d8322ceefff
TimeStamp::ProcessCreations()'s aIsInconsistent outparam is ignored by the
majority of its caller. This patch makes it optional. Notably, this makes
ProcessCreation() easier to use in a constructor's initializer list.
This changes JS_smprintf to return UniqueChars, rather than relying on
manual memory management.
MozReview-Commit-ID: ENjQJODYdD1
--HG--
extra : rebase_source : 4c8ad4719dce205a7ef25e41eca25c5af793bb47
With changes introduced in bug 1356066 I made the xpc_LocalizeContext be
called on each app locale change to update the default locale in each context.
Unfortunately, this function is also assigning the locale callbacks and
with my change it started doing it on each language change.
In this patch I'm first checking if we do have XPCLocaleCallbacks for the
given context and only if we don't, I assign them.
MozReview-Commit-ID: 7AiCsJfKBID
--HG--
extra : rebase_source : 1efe65895759ffc07e0047d063a405d757cb1092
NS_SetCurrentThreadName() is added as an alternative to PR_SetCurrentThreadName()
inside libxul. The thread names are collected in the form of crash annotation to
be processed on socorro.
MozReview-Commit-ID: 4RpAWzTuvPs
clang's -Wcomma warning warns about suspicious use of the comma operator such as between two statements or to call a function for side effects within an expression.
js/src/builtin/MapObject.cpp:786:48 [-Wcomma] possible misuse of comma operator here
js/src/builtin/MapObject.cpp:1371:48 [-Wcomma] possible misuse of comma operator here
js/src/builtin/RegExp.cpp:1266:62 [-Wcomma] possible misuse of comma operator here
js/src/jit/x64/BaseAssembler-x64.h:624:99 [-Wcomma] possible misuse of comma operator here
js/src/jsarray.cpp:2416:27 [-Wcomma] possible misuse of comma operator here
js/src/jscompartment.cpp:120:48 [-Wcomma] possible misuse of comma operator here
js/src/jsstr.cpp:3346:14 [-Wcomma] possible misuse of comma operator here
js/xpconnect/src/XPCWrappedNativeJSOps.cpp:316:71 [-Wcomma] possible misuse of comma operator here
MozReview-Commit-ID: BbT4otUXczV
--HG--
extra : rebase_source : b232d10b5280c567f8fe390fcb56012b78da580a
This is necessary to allow helper threads to attempt large allocations and recover from fragmentation situations with the LargeAllocationFailureCallback.
MozReview-Commit-ID: AyA3pbXcaYy
--HG--
extra : rebase_source : 7a5feb779b690ec7f123481e76f2390c850dac91
To run JS in separate cooperative threads, we need to split up per-thread state
from per-runtime state. This patch does that for XPConnect.
MozReview-Commit-ID: 407SlJ7nR6v
These files were being excluding because we thought they used plarena.h, but it
turns out they did not. A few tweaks needed to be made to clarify whether we
wanted to use mozilla::UniquePtr or js::UniquePtr.
MozReview-Commit-ID: 1su5dO3rR0T
These files were being excluding because we thought they used plarena.h, but it
turns out they did not. A few tweaks needed to be made to clarify whether we
wanted to use mozilla::UniquePtr or js::UniquePtr.
MozReview-Commit-ID: 1su5dO3rR0T
These files were being excluding because we thought they used plarena.h, but it
turns out they did not. A few tweaks needed to be made to clarify whether we
wanted to use mozilla::UniquePtr or js::UniquePtr.
MozReview-Commit-ID: 1su5dO3rR0T
By bug 1346674, we don't use NSILOCALE_* for unicode conversion in XPC/JS. So we should use NS_CopyNativeToUnicode to get a rid of nsIPlatformCharset.
MozReview-Commit-ID: Kp2jijN8On9
Now that we join on the thread exiting, we no longer need to have the thread
explicitly tell us it's shutting down.
MozReview-Commit-ID: LycPjUvyeX
--HG--
extra : rebase_source : 7b3d21c3d8de73a1ed511c7d6efefe2a73b2e02a
Currently, JS sampling has major problems.
- JS sampling is enabled for all JS threads from the thread that runs
locked_profiler_start() -- currently only the main thread -- but the JS
engine can't handle enabling from off-thread, and asserts. This makes
profiling workers impossible in a debug build.
- No JS thread will be JS sampled unless enableJSSampling() is called, but that
only happens in locked_profiler_start(). That means any worker threads
created while the profiler is active won't be JS sampled.
- Only the thread that runs locked_profiler_stop() -- currently only the main
thread -- ever calls disableJSSampling(). This means that worker threads that
start being JS sampled never stop being JS sampled.
This patch fixes these three problems in the following ways.
- locked_profiler_start() now sets a flag in PseudoStack that indicates
JS sampling is desired, but doesn't directly enable it. Instead, the JS
thread polls that flag and enables JS sampling itself when it sees the flag
is set. The polling is done by the interrupt callback. There was already a
flag of this sort (mJSSampling) but the new one is better.
This required adding a call to profiler_js_operation_callback() to the
InterruptCallback() in XPCJSContext.cpp. (In comparison, the
InterruptCallback() in dom/workers/RuntimeService.cpp already had such a
call.)
- RegisterCurrentThread() now requests JS sampling of a JS thread when the
profiler is active, the thread is being profiled, and JS sampling is enabled.
- locked_profiler_stop() now calls stopJSSampling() on all live threads.
The patch makes the following smaller changes as well.
- Renames profiler_js_operation_callback() as profiler_js_interrupt_callback(),
because "interrupt callback" is the standard name (viz.
JS_AddInterruptCallback()).
- Calls js::RegisterContextProfilingEventMarker() with nullptr when stopping
JS sampling, so that ProfilerJSEventMarker won't fire unnecessarily.
- Some minor formatting changes.
--HG--
extra : rebase_source : 372f94c963a9e5b2493389892499b1ca205ebc2f
PseudoContext::sampleContext() is always called immediately after
profiler_get_pseudo_stack(). This patch introduces profiler_set_js_context()
and profiler_clear_js_context(), which replace the profiler_get_pseudo_stack()
+ sampleContext() pairs. This takes us a step closer to not having to export
PseudoStack outside the profiler.
--HG--
extra : rebase_source : 8558d1600eafd395cc696d31f3d21fb52a1a74b0
In many cases, to speed up start, compiling a ScriptSource will not
compile the functions themselves, but will rather syntax-parse them
(to check for syntax errors), leaving full compilation for
later. However, if we find ourselves in a case in which the function
is needed almost immediately, we need to full-parse the function
immediately after the syntax-parse, which is wasteful.
This changeset intends to measure how often this happens, by exporting
through Telemetry the duration between the end of the syntax-parse and
the start of the full-parse for each function.
As a memory optimization, instead of storing a timestamp for the
syntax-parse of each function, we store a single timestamp for an
entire ScriptSource. This assumes that all functions of the
ScriptSource are syntax-parsed at approximately the same instant,
which should be mostly true for everything except perhaps `eval` and
`new Function`. Then, when time comes to delazify a function, we
simply determine the time elapsed since the ScriptSource was compiled.
Histogram JS_PARSER_COMPILE_LAZY_AFTER_MS starts at 10ms (anything
smaller is often not measurable) and stops at 10s (anything larger can
safely be said to be not wasteful).
MozReview-Commit-ID: 6Ycy2OIIiAt
--HG--
extra : rebase_source : 0ccd6f51189b3ad8056e9f39e267235d68f6e2db
The profiler can currently handle nested calls to profiler_{init,shutdown}() --
only the first call to profiler_init() and the last call to profiler_shutdown()
do anything. And sure enough, we have the following.
- Outer init/shutdown pairs in XRE_main()/XRE_InitChildProcess() (via
GeckoProfilerInitRAII).
- Inner init/shutdown pairs in NS_InitXPCOM2()/NS_InitMinimalXPCOM() (both shut
down in ShutdownXPCOM()).
This is a bit silly, so the patch removes the inner pairs, and adds a
now-needed pair in XRE_XPCShellMain. This will allow gInitCount -- which tracks
the nesting depth -- to be removed in a future patch.
--HG--
extra : rebase_source : 7e8dc6ce81ce10269d2db6a7bf32852c396dba0e
Without this change, we could do a "short" get of a string (e.g. from
XMLHttpRequest), then do another get that returns the same stringbuffer but a
longer length. But we wouldn't notice, hit our cache, and return the same,
too-short, external string. The site would not see the new data it should have
seen.
The problem is that JSJitGetterInfo doesn't contain a callee. So we can't use
xpc::XrayAwareCalleeGlobal in a specialized getter, because we don't have our
callee function available.
nsIXPCScriptable flags handling in xpc_map_end.h is a bit of a mess.
- Half the flags relate to whether various functions are defined (PreCreate,
GetProperty, etc). These are set using the XPC_MAP_WANT_* macros;
for each one xpc_map_end.h inserts the corresponding flag using the
preprocessor (see XPC_MAP_CLASSNAME::GetScriptableFlags()).
- The other half of the flags relate to other things (IS_GLOBAL_OBJECT,
DONT_REFLECT_INTERFACE_NAMES, etc). These are set using the XPC_MAP_FLAGS
macro.
Having two similar but different mechanisms to set the flags for a class is
confusing. (Indeed, until recently we had some classes where a single flag was
redundantly specified via both mechanisms.) Note also that the classes done in
dom/base/nsIDOMClassInfo.h also specify all the flags in a single value,
similar to how XPC_MAP_FLAGS works.
This patch removes the XPC_MAP_WANT_* macros. All flags are now set
via XPC_MAP_FLAGS. This is a significant simplification to xpc_map_end.h and
all the places that use it.
The downside of this change is that I had to change the flag constants from
class constants (i.e. nsIXPCScriptable::FOO) to macros (i.e.
NSIXPCSCRIPTABLE_FOO) because they need to be used in #if statements like this
in xpc_map_end.h:
#if !((XPC_MAP_FLAGS) & NSIXPCSCRIPTABLE_WANT_PRECREATE)
and you can't use a '::'-qualified name inside a #if. I think this downside is
outweighed by the simplification described above.
Overall the patch removes 80 lines of code.
--HG--
extra : rebase_source : 6d5c341d0deba8f1529d81c17bb8819e09620b05
XPCNativeScriptableCreateInfo is now a very thin wrapper around
nsIXPCScriptable. Removing it simplifies things quite a bit.
Note especially the change to GatherScriptableCreateInfo(), which is a
confusing function. Previously its fourth argument was never touched it was
called, but it did have a return value. Now the fourth argument is touched and
effectively replaces that return value, and the function now returns void.
* * *
Bug 1330904 - fixups. r=mccr8.
I will fold this into the previous patch before landing.
--HG--
extra : rebase_source : 22e7fd0c44dd7c4174f8edf3e1d3ae362bf95757
XPCNativeScriptableInfo is now a very thin wrapper around nsIXPCScriptable, and
it uses manual memory management. Removing it simplifies things quite a bit.
In particular, when setting XPCWrappedNative::mScriptable in
XPCWrappedNative::WrapNewGlobal() and XPCWrappedNative::Init() we no longer
have to worry about sharing the XPCNativeScriptableInfo object with the proto.
And XPCWrappedNative::{Init,Destroy}() have similar simplifications.
--HG--
extra : rebase_source : e58eb28f1574224a8e8badf25fcfa25e5a5b8ad8
WantFoo() and the similar methods remain, but they've been moved from
XPCNativeScriptableFlags to nsIXPCScriptable.
One consequence of this change is that in places where we used to get the flags
from an XPCNativeScriptableCreateInfo we now need a null check on the
nsIXPCScriptable. (This isn't true when getting flags from
XPCNativeScriptableInfo, however, because nsIXPCScriptable is always non-null
within that type.)
--HG--
extra : rebase_source : 3d1e1d1c313b4629bb2e337cc2fb7c0d1092ed99
I'd like to remove XPC_MAP_WANT_* altogether and use XPC_MAP_FLAGS for all the
nsIXPCScriptable flag setting, but I haven't worked out how to handle the
method definitions in xpc_map_end.h yet. In the meantime, it seems good to make
the flag setting more consistent and explicit.
In particular, the three "Module" classes have "#define XPC_MAP_WANT_CALL" and
"#define XPC_MAP_FLAGS nsIXPCScriptable::WANT_CALL" which both have the same
effect. The patch removes the latter, to make them consistent with other
classes.
--HG--
extra : rebase_source : 3119e895809bb14e63f61e4e440c84e16cc4c5f9
As far as I can tell, this covers all the remaining threads which we start
using PR_CreateThread, except the ones that are created inside NSPR or NSS,
and except for the Shutdown Watchdog thread in nsTerminator.cpp and the
CacheIO thread. The Shutdown Watchdog thread stays alive past leak detection
during shutdown (by design), so we'd report leaks if we profiled it. The
CacheIO thread seems to stay alive past shutdown leak detection sometimes as
well.
This adds a AutoProfilerRegister stack class for easy registering and
unregistering. There are a few places where we still call
profiler_register_thread() and profiler_unregister_thread() manually, either
because registration happens conditionally, or because there is a variable that
gets put on the stack before the AutoProfilerRegister (e.g. a dynamically
generated thread name). AutoProfilerRegister needs to be the first object on
the stack because it uses its own `this` pointer as the stack top address.
MozReview-Commit-ID: 3vwhS55Yzt
--HG--
extra : rebase_source : 56dd27282e7bd09a7e7dc7ca09ccfe3a0198e7af
