Have the public interface just use void* pointers so that we don't have to
worry about symbol visibility.
(Includes some reformatting of a macro because clang-format required it)
Differential Revision: https://phabricator.services.mozilla.com/D49097
--HG--
extra : moz-landing-system : lando
Please note that it is the first reformat with clang-format 9
I only saw a fix in the .mm file
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D49056
--HG--
extra : moz-landing-system : lando
This lets us avoid pointlessly checking release assertions in a safe comparison loop.
In particular, for Span<char>, this lets the compiler use memcmp, speeding up comparisons by over an order of magnitude.
Differential Revision: https://phabricator.services.mozilla.com/D48097
--HG--
extra : moz-landing-system : lando
I am not aware of anything that depends on StartupCache being a
zip file, and since I want to use lz4 compression because inflate
is showing up quite a lot in profiles, it's simplest to just use
a custom format. This loosely mimicks the ScriptPreloader code,
with a few diversions:
- Obviously the contents of the cache are compressed. I used lz4
for this as I hit the same file size as deflate at a compression
level of 1, which is what the StartupCache was using previously,
while decompressing an order of magnitude faster. Seemed like
the most conservative change to make. I think it's worth
investigating what the impact of slower algs with higher ratios
would be, but for right now I settled on this. We'd probably
want to look at zstd next.
- I use streaming compression for this via lz4frame. This is not
strictly necessary, but has the benefit of not requiring as
much memory for large buffers, as well as giving us a built-in
checksum, rather than relying on the much slower CRC that we
were doing with the zip-based approach.
- I coded the serialization of the headers inline, since I had to
jump back to add the offset and compressed size, which would
make the nice Code(...) method for the ScriptPreloader stuff
rather more complex. Open to cleaner solutions, but moving it
out just felt like extra hoops for the reader to jump through
to understand without the benefit of being more concise.
Differential Revision: https://phabricator.services.mozilla.com/D34652
--HG--
extra : moz-landing-system : lando
Adds an explicit error mapping function to Result, to simplify
using MOZ_TRY... macros.
Differential Revision: https://phabricator.services.mozilla.com/D47466
--HG--
extra : moz-landing-system : lando
I opted to go with what I perceived as the more expedient route
of leaving lz4 roughly where it is and just adding to that. The
biggest complication was xxhash, which is included elsewhere.
I'm not generally proficient with build-related things though so
my solution may be wrong and not just ugly.
Differential Revision: https://phabricator.services.mozilla.com/D30640
--HG--
rename : mfbt/lz4.c => mfbt/lz4/lz4.c
rename : mfbt/lz4.h => mfbt/lz4/lz4.h
extra : moz-landing-system : lando
I am not aware of anything that depends on StartupCache being a
zip file, and since I want to use lz4 compression because inflate
is showing up quite a lot in profiles, it's simplest to just use
a custom format. This loosely mimicks the ScriptPreloader code,
with a few diversions:
- Obviously the contents of the cache are compressed. I used lz4
for this as I hit the same file size as deflate at a compression
level of 1, which is what the StartupCache was using previously,
while decompressing an order of magnitude faster. Seemed like
the most conservative change to make. I think it's worth
investigating what the impact of slower algs with higher ratios
would be, but for right now I settled on this. We'd probably
want to look at zstd next.
- I use streaming compression for this via lz4frame. This is not
strictly necessary, but has the benefit of not requiring as
much memory for large buffers, as well as giving us a built-in
checksum, rather than relying on the much slower CRC that we
were doing with the zip-based approach.
- I coded the serialization of the headers inline, since I had to
jump back to add the offset and compressed size, which would
make the nice Code(...) method for the ScriptPreloader stuff
rather more complex. Open to cleaner solutions, but moving it
out just felt like extra hoops for the reader to jump through
to understand without the benefit of being more concise.
Differential Revision: https://phabricator.services.mozilla.com/D34652
--HG--
extra : moz-landing-system : lando
Adds an explicit error mapping function to Result, to simplify
using MOZ_TRY... macros.
Differential Revision: https://phabricator.services.mozilla.com/D47466
--HG--
extra : moz-landing-system : lando
I opted to go with what I perceived as the more expedient route
of leaving lz4 roughly where it is and just adding to that. The
biggest complication was xxhash, which is included elsewhere.
I'm not generally proficient with build-related things though so
my solution may be wrong and not just ugly.
Differential Revision: https://phabricator.services.mozilla.com/D30640
--HG--
rename : mfbt/lz4.c => mfbt/lz4/lz4.c
rename : mfbt/lz4.h => mfbt/lz4/lz4.h
extra : moz-landing-system : lando
Defines an android-only version of nsTraceRefcnt::WalkTheStack that takes a function callback, which outputs the stack frame buffer to `__android_log_print`. Also uses `__wrap_dladdr` in MozDescribeCodeAddress, which outputs slightly more informative data for the stack trace (instead of instances of '???/??? [???]').
Differential Revision: https://phabricator.services.mozilla.com/D46868
--HG--
extra : moz-landing-system : lando
Defines an android-only version of nsTraceRefcnt::WalkTheStack that takes a function callback, which outputs the stack frame buffer to `__android_log_print`. Also uses `__wrap_dladdr` in MozDescribeCodeAddress, which outputs slightly more informative data for the stack trace (instead of instances of '???/??? [???]').
Differential Revision: https://phabricator.services.mozilla.com/D46868
--HG--
extra : moz-landing-system : lando
It doesn't really make sense to enforce this behavior for calls on stack
variables (which presumably we then want to do something with) and doesn't
necessarily make sense to enforce it for member variables either.
Differential Revision: https://phabricator.services.mozilla.com/D46105
--HG--
extra : moz-landing-system : lando
The only plausible reason I can think of to include this header here is
for `wchar_t`, but `wchar_t` is a builtin type. So let's get rid of the
header.
Differential Revision: https://phabricator.services.mozilla.com/D45514
--HG--
extra : moz-landing-system : lando
We don't support stlport anymore, we don't use any of these macros, and
even if we did, there are probably better ways to do what we want than
by depending on the subtleties of how C++ standard libraries version
themselves.
Differential Revision: https://phabricator.services.mozilla.com/D43677
--HG--
extra : moz-landing-system : lando
MANUAL PUSH: Because the hook says I need to for this backout.
--HG--
extra : rebase_source : dd86738d1fbc711e87354e27a89f91f5c6070a34
extra : amend_source : 59ae6c7936c9b7e0ecef72ed962f5ed41efe0b5a
This patch adds smart pointers to be used for initializing objects as C++11
"magic statics" -- that is, they are able to take advantage of C++11's
guarantee of thread safety during initialization by atomically constructing
both the smart pointer itself as well as the object being pointed to.
Unlike Static{Auto,Ref}Ptr, they have non-trivial constructors, though they
must still have trivial destructors to prevent emission of atexit calls.
The new classes use the new `MOZ_STATIC_LOCAL_CLASS` annotation which ensures
their instantiations are static locals and prevents non-trivial destructors.
Differential Revision: https://phabricator.services.mozilla.com/D40092
--HG--
rename : xpcom/base/StaticPtr.h => xpcom/base/StaticLocalPtr.h
extra : moz-landing-system : lando
I did not add a separate macro for `MOZ_TRIVIAL_DTOR` as I could not really
think of a use case for it. Let me know if you prefer that I add it as a
distinct macro.
Differential Revision: https://phabricator.services.mozilla.com/D39719
--HG--
extra : moz-landing-system : lando
I did not add a separate macro for `MOZ_TRIVIAL_DTOR` as I could not really
think of a use case for it. Let me know if you prefer that I add it as a
distinct macro.
Differential Revision: https://phabricator.services.mozilla.com/D39719
--HG--
extra : moz-landing-system : lando
I did not add a separate macro for `MOZ_TRIVIAL_DTOR` as I could not really
think of a use case for it. Let me know if you prefer that I add it as a
distinct macro.
Differential Revision: https://phabricator.services.mozilla.com/D39719
--HG--
extra : moz-landing-system : lando
Jeff Walden
Philip Chimento
Sylvestre Ledru
Ryan VanderMeulen
Jon Coppeard
Tooru Fujisawa
Peter Van der Beken
Adrian Wielgosik
Doug Thayer
Cosmin Sabou
Henri Sivonen
kriswright
Bogdan Tara
Boris Zbarsky
Emilio Cobos Álvarez
Liang-Heng Chen
Honza Bambas
Nathan Froyd
Tom Ritter
Eric Rahm
Coroiu Cristina
Brian Hackett
Nika Layzell
Aaron Klotz
Mihai Alexandru Michis