To add conditional JS::StartIncrementalEncoding, and also to add a bytecode
decoding branch, replace nsJSUtils::CompileModule with raw JSAPI calls with
Stencil.
Differential Revision: https://phabricator.services.mozilla.com/D140291
To add conditional JS::StartIncrementalEncoding, and also to add a bytecode
decoding branch, replace nsJSUtils::CompileModule with raw JSAPI calls with
Stencil.
Differential Revision: https://phabricator.services.mozilla.com/D140291
This builds on the existing static components infrastructure to allow defining
a Services.jsm-type services cache with no runtime memory overhead for any
services until they're accessed.
Any class entry with a 'js_name' attribute automatically becomes available on
the services cache with that name, and any interfaces listed in its
'interfaces' list are automatically queried on it.
Differential Revision: https://phabricator.services.mozilla.com/D81417
This builds on the existing static components infrastructure to allow defining
a Services.jsm-type services cache with no runtime memory overhead for any
services until they're accessed.
Any class entry with a 'js_name' attribute automatically becomes available on
the services cache with that name, and any interfaces listed in its
'interfaces' list are automatically queried on it.
Differential Revision: https://phabricator.services.mozilla.com/D81417
We can reduce the size of the SSO by removing the element slot entirely, and instead retrieve the element through a callback function. The callback will take in the value in the private slot of the SSO, which is either a LoadedScript* (from the browser) or a JSObject* (from the shell). In addition, this removes the requirement of having a script dom element ready when parsing a JS script which can open up new opportunities for performance.
Differential Revision: https://phabricator.services.mozilla.com/D70417
We can reduce the size of the SSO by removing the element slot entirely, and instead retrieve the element through a callback function. The callback will take in the value in the private slot of the SSO, which is either a LoadedScript* (from the browser) or a JSObject* (from the shell). In addition, this removes the requirement of having a script dom element ready when parsing a JS script which can open up new opportunities for performance.
Differential Revision: https://phabricator.services.mozilla.com/D70417
Now that we have UTF8String in the WebIDL, we can remove quite a few of the
conversions. Do that, and lift the remaining string conversions up as needed.
Also deindent Servo_ComputeColor while touching it.
Most of the remaining copies are because either bug 1606994, or because they're
WebIDL attributes that we still need to serialize back as UTF-16 (bug 1606995).
Differential Revision: https://phabricator.services.mozilla.com/D58687
--HG--
extra : moz-landing-system : lando
This was generated with:
```
rg -l -g '*.{cpp,h}' MOZ_XBL . | while read FILE ; do
echo $FILE
unifdef -m -UMOZ_XBL $FILE
done
```
After this, I manually removed the directive in nsContentUtils.cpp due to:
unifdef: ./dom/base/nsContentUtils.cpp: 4630: Unterminated string literal
unifdef: Output may be truncated
Differential Revision: https://phabricator.services.mozilla.com/D51337
--HG--
extra : moz-landing-system : lando
The codesize impact is approximately 0 (actually positive by a a few KB),
because AssignJSString is not inlined.
If we were to force-inline AssignJSString, that would actually _save_ ~115KB
based on bloaty measurements for linux64 shippable opt builds (so with LTO),
because then ConvertJSValueToString stops being inlined in bindings.
Given that ConvertJSValueToString pretty much always calls AssignJSString, so
there is no slowdown from changing which of them is inlined, this is _really_
tempting to do, but I don't want to mess with compiler inlining heuristics...
Inlining both AssignJSString and ConvertJSValueToString increases codesize by
~2MB, so that's definitely _not_ desirable.
Differential Revision: https://phabricator.services.mozilla.com/D50627
--HG--
extra : moz-landing-system : lando
We want to remove flat strings (JSFlatString). With this patch we only expose
linear strings (JSLinearString) to API consumers.
This is very mechanical for the most part, because code typically only cares
about linear strings and not the null-termination aspect.
CTypes's Library.cpp has some Windows-specific code where we relied on null-terminated
strings. This patch adds JS_CopyStringCharsZ for that use case.
Differential Revision: https://phabricator.services.mozilla.com/D48314
--HG--
extra : moz-landing-system : lando
When XBL is disabled, no code in dom/xbl will be built. Also, adds ifdefs
to remove any of the XBL related code elsewhere. There's definitely more
that can be done here, but I think it's better to wait to do the rest of
the cleanup when we actually remove the code.
Depends on D45612
Differential Revision: https://phabricator.services.mozilla.com/D45613
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
Jon Coppeard
Tooru Fujisawa
Csoregi Natalia
André Bargull
Matthew Gaudet
Ted Campbell
yulia
Razvan Maries
Bogdan Tara
Simon Giesecke
Jeff Walden
Kris Maglione
Cosmin Sabou
Denis Palmeiro
Dorel Luca
Sylvestre Ledru
Emilio Cobos Álvarez
Brian Grinstead
Boris Zbarsky
Jan de Mooij
Brendan Dahl
Nicholas Nethercote
Andrea Marchesini
Yoshi Cheng-Hao Huang