It turns out that not recycling some kinds of chunk can lead to the
recycle queue being starved in some scenarios. When that happens, we end
up mmap()ing new memory, but that turns out to be significantly slower.
So instead of not recycling huge chunks, we force-clean them, before
madvising so that the pages can still be reclaimed in case of memory
pressure.
--HG--
extra : rebase_source : 2dbd028daca92c9cd7c8079eb3dc5a0cfa06495b
~AzureState is expensive, especially in GlyphBufferAzure::Flush, which is a high
fan-in function.
MozReview-Commit-ID: 4JfjMje0Kgs
--HG--
extra : rebase_source : bbc2f06871d9bde9130ddb95d053d16a3f2a091d
Also, switch the hover quirk to the same mechanism.
Bug: 1379696
Reviewed-By: bholley
MozReview-Commit-ID: KrmNqNyASf6
Source-Repo: https://github.com/servo/servo
Source-Revision: 8fa2a262dc8f2dcab884aead38439ba8756518dc
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : c68725c4b5f088cc4ae280059486b62f6b02c43e
This allows us to reuse the minimum bound guards on the pref values in other
places that want to use the prefs.
MozReview-Commit-ID: 7XKuM5u1GB8
--HG--
extra : rebase_source : 9cf85c7cbe2e8511ad2db59e7bf7ba6e8db79883
Reviewed by @emilio in https://bugzilla.mozilla.org/show_bug.cgi?id=1352669.
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] There are tests for these changes
Source-Repo: https://github.com/servo/servo
Source-Revision: 2ddbc92d90ec8df9e5bf4630cd3e93759da81649
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 87c38834194b9cb1d5fdfa4303c0754f866b6613
So we can remove AbstractMediaDecoder::CanonicalDurationOrNull() later.
MozReview-Commit-ID: 6zJCFDsCZPC
--HG--
extra : rebase_source : 66af1674651667a2ab9e82b85e5c730f8eb5c227
extra : intermediate-source : 6c5eccd5fc68bf663e1ffa9d5b57c5a2a2721b14
extra : source : 4b30670e2d75260b21fa953f9c7219e3e485c396
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.
The idea is that CastableObjectUnwrapper will want to have a MutableHandle for
the thing it's unwrapping whenever its target is a raw pointer. Since we have
convenient MutableHandle<Value> in most cases, it's easier to switch
CastableObjectUnwrapper to working with MutableHandle<Value> or Handle<Value>
instead of trying to get MutableHandle<JSObject*> in the right places.
There are basically two changes here:
1) Make CastableObjectUnwrapper work with at thing that looks like a Value.
2) Change various callsites to pass in MutableHandle<Value>, in addition to a
Handle<Value>, into the JS-to-C++ conversion templates. The
MutableHandle<Value> is passed as ${maybeMutableVal}. It may not actually
end up being a MutableHandle in some cases.
The reason for passing both a Handle and a MutableHandle is that when the thing
we actually have is a Rooted named "foo" the Handle will be "foo" but the
MutableHandle is most naturally written as "&foo". This is not a problem if
you're just passing it through, but if you want to test whether it's an object,
say, you have a problem. Writing "foo.isObject()" is ok, but "&foo.isObject()"
is not, and neither is "(&foo).isObject()". This could be worked around by
passing the MutableHandle as "JS::MutableHandle<JS::Value>(&foo)" or something,
and then "JS::MutableHandle<JS::Value>(&foo).isObject()" does work. But it
makes the code very hard to read.
So we just pass both things along; ${val} should be used for readonly access and
${maybeMutableVal} any time you really want a MutableHandle.
Starting from 52, NativeKey::HandleCharMessage() ignores all control characters. However, some keyboard layout utilities may send WM_CHAR message whose wParam is '\r' for emulating pressing Enter key. For supporting such utilities, we should dispatch Enter keypress event when HandleCharMessage() receives such event.
Note that this patch does NOT support a pair of WM_KEYDOWN and WM_CHAR whose wParam is '\r' but the WM_KEYDOWN isn't VK_RETURN. If there is such case, we need to support it too. However, it needs a lot of code changes. So, we shouldn't support it until such bug is filed actually.
MozReview-Commit-ID: CWyvBtLmXgg
--HG--
extra : rebase_source : 6e9b27dc2fb9eb75626cdd5ab339d348a7be3040
This is the Servo side of [bug 1372464](https://bugzilla.mozilla.org/show_bug.cgi?id=1372464).
Source-Repo: https://github.com/servo/servo
Source-Revision: 95a85a301f1d014c45448a4d5d4f5a8497904af6
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : be1244951c8d868b79ee09b37d1f26615f6ec89f
Enable stylo in Firefox Nightly builds for macOS so we can
get testing feedback until we have addressed issues blocking
enabling it for developer builds.
MozReview-Commit-ID: 3y0QT4oiBpt
--HG--
extra : rebase_source : 531162da334a6d124dcd7328f45d677cb4933551
