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.
Other browsers do not support any of these (IIRC), telemetry reports
essentially zero usage, and supporting them is contrary to the DOM spec.
Notes on specific events:
CommandEvent and SimpleGestureEvent: These are not supposed to be
web-exposed APIs, so I hid the interfaces from web content too
(necessary to avoid test_all_synthetic_events.html failures).
DataContainerEvent: This was a non-standard substitute for CustomEvent
that seemed to have only one user, so I removed it entirely and switched
the user (MozillaFileLogger.js) to CustomEvent.
ScrollAreaEvent: This is entirely non-standard, but we apparently expose
it deliberately to web content, so I didn't see any reason to remove it
from createEvent.
SimpleGestureEvent and XULCommandEvent: Can still be created from
createEvent(), but not by content.
TimeEvent: This is still in because it has no constructor, so there's no
other way to create it. Ideally we'd update the SMIL spec to add a
constructor. I did remove TimeEvents.
MozReview-Commit-ID: 7Yi2oCl9SM2
--HG--
extra : rebase_source : 199ab921acfc531b8b85e77f90fcd799b03c887b
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
mSystemPrincipal is an nsCOMPtr so it does not need to be explicitly
initialized.
Fields don't have to be lined up.
Empty function bodies don't need to be commented as such.
The blank line at the start of mozJSComponentLoader.cpp prevents Emacs
from using the mode line.
MozReview-Commit-ID: 7Az1x8jmxTI
--HG--
extra : rebase_source : 2d818074d82f9a6b1041983efd7a81bde9870619
Also, be consistent with the rest of the code and use a handle
typedef in one place.
MozReview-Commit-ID: KY3cnLemoUl
--HG--
extra : rebase_source : 4c3ae2750c868b5401a686dd164adbd04b45a0b5
Sebastian Hengst
Andrew Swan
Phil Ringnalda
Jan de Mooij
Bill McCloskey
Wes Kocher
Tom Tromey
Jon Coppeard
Carsten "Tomcat" Book
Nicholas Nethercote
Aryeh Gregor
Zibi Braniecki
Hannes Verschore
Cervantes Yu
Chris Peterson
Kris Maglione
Andrew McCreight
Eric Rahm
Luke Wagner
Florian Queze