As per mozglue/static/README:
> mozglue/static contains parts of the mozglue library that can/should be
> statically linked to e.g. js/Gecko.
The compression part of MFBT is a good candidate for this.
Differential Revision: https://phabricator.services.mozilla.com/D221565
This is still fairly incomplete (i.e. no capturing, etc), but it allows
a transition to "start", and then finish (on the next frame always, for
now) or timeout, appropriately.
I think it's in a reviewable shape, given that. There's one known
divergence from the spec, which is described in
https://github.com/w3c/csswg-drafts/issues/10822
Differential Revision: https://phabricator.services.mozilla.com/D220843
This is still fairly incomplete (i.e. no capturing, etc), but it allows
a transition to "start", and then finish (on the next frame always, for
now) or timeout, appropriately.
I think it's in a reviewable shape, given that. There's one known
divergence from the spec, which is described in
https://github.com/w3c/csswg-drafts/issues/10822
Differential Revision: https://phabricator.services.mozilla.com/D220843
This lets us trigger a minor GC if we're allocating many long strings. This avoids
a memory spike on the test case reported in the bug.
Differential Revision: https://phabricator.services.mozilla.com/D220388
Fixes the conversion in `mozilla::FloatingPoint` so we can add the specialisation
`mozilla::detail::FloatingPointTrait<js::float16>`.
And then update "TypedArrayObject.cpp" to directly use `mozilla::FloatingPoint`.
Differential Revision: https://phabricator.services.mozilla.com/D217981
In `JSStringBuilder` (derives from `js::StringBuffer`) we now reserve space for the
`mozilla::StringBuffer` header in the internal vector. When creating a long string, we can
then directly initialize this header without having to move all characters in memory.
Differential Revision: https://phabricator.services.mozilla.com/D216694
This avoids some regressions on a few Speedometer 3 (async) sub tests.
The problem is likely more jemalloc lock contention during GC when using the
main malloc heap. Using SpiderMonkey's string buffer arena avoids that and
matches previous behavior better.
Differential Revision: https://phabricator.services.mozilla.com/D215522
If there are more than 500 bytes of string data, use a `StringBuffer` instead of raw malloc.
This helps avoid memory usage regressions because for shorter strings `StringBuffer` has
relatively more overhead.
Differential Revision: https://phabricator.services.mozilla.com/D215211
`mozilla::StringBuffer` uses `RefCountLogger`, but this was a no-op when included in
SpiderMonkey code (`MOZILLA_INTERNAL_API` is not defined in that case). This resulted
in leakcheck failures when string buffers are used directly in SpiderMonkey.
This patch changes the calls to `NS_LogAddRef` and `NS_LogRelease` to go through a
function pointer. This also makes it possible to use a different implementation in
SpiderMonkey shell builds if we ever want to.
Differential Revision: https://phabricator.services.mozilla.com/D213968
This change optimises the PHC hot path by reducing updates to sAllocDelay
and sNow:
* tlsAllocDelay has been created to create thread-local allocation delays,
when they expire then the shared sAllocDelay is checked.
* sNow is updated only when not executing the fast path.
This change also:
* Previously the thread that saw sAllocDelay == 0 would be the one to make
the allocation, the ReleaseAquire semantics ensured that exactly one
thread would see this. Now all threads that see sAllocDelay <= 0 will
attempt a PHC allocation, this is later checked by atomically resetting
sAllocDelay.
* Removes the logic that checks if the delay has wrapped
while PHC was disabled on the current thread. This isn't needed anymore
because we now make PHC allocations for all sAllocDelay < 0, assuming
that threads are disabled for less than UINT32_MAX/2 allocations.
* Moves ShouldMakeNewAllocations out of the hot-path.
Differential Revision: https://phabricator.services.mozilla.com/D206469
`mozilla::StringBuffer` uses `RefCountLogger`, but this was a no-op when included in
SpiderMonkey code (`MOZILLA_INTERNAL_API` is not defined in that case). This resulted
in leakcheck failures when string buffers are used directly in SpiderMonkey.
This patch changes the calls to `NS_LogAddRef` and `NS_LogRelease` to go through a
function pointer. This also makes it possible to use a different implementation in
SpiderMonkey shell builds if we ever want to.
Differential Revision: https://phabricator.services.mozilla.com/D213968
This adds initial support for JS strings that have a refcounted `mozilla::StringBuffer`
instead of a raw `malloc` buffer.
The `newString` testing function has two new options. This lets us allocate a new JS string
with a new buffer or a new JS string that reuses the underlying string buffer.
After this we can start using this to replace external strings. We can also allocate more JS
strings with `StringBuffer`s instead of raw `malloc` buffers.
Differential Revision: https://phabricator.services.mozilla.com/D212110
Inline Create() and Realloc() so that we don't get negative leaks, since
were that code end up in mozglue, it wouldn't have access to the logging
machinery.
Differential Revision: https://phabricator.services.mozilla.com/D209663
C++20 renamed the `std::memory_order::memory_order_*` enum constants to `std::memory_order::*`.
https://en.cppreference.com/w/cpp/atomic/memory_order
C++17 supports:
`std::memory_order_relaxed`
`std::memory_order::memory_order_relaxed`
But C++20 supports:
`std::memory_order_relaxed`
`std::memory_order::memory_order::relaxed`
Thus, `std::memory_order_relaxed` is the only shared name if we want to support compiling Firefox with -std=c++17 and -std=c++20 as we transition mozilla-central from C++17 to C++20.
Differential Revision: https://phabricator.services.mozilla.com/D208963
MOZ_ASSERT is only checked in debug builds, so release builds' tests are not checking these assertions.
Depends on D207373
Differential Revision: https://phabricator.services.mozilla.com/D207374
Now that -Wc++2a-compat is no longer enabled (bug 1887580), we don't need these pragmas disabling -Wc++2a-compat warnings about u8"" string literals' type changing from const char[] in C++17 to const char8_t[] in C++20.
Differential Revision: https://phabricator.services.mozilla.com/D206742
Mike Hommey
Emilio Cobos Álvarez
Butkovits Atila
Jan de Mooij
Tamas Szentpeteri
André Bargull
Chun-Min Chang
fanc999
jake
Ryan VanderMeulen
Sylvestre Ledru
Paul Adenot
Stanca Serban
Paul Bone
serge-sans-paille
Iulian Moraru
Otto Länd
Andreas Pehrson
Chris Peterson
Jeff Muizelaar
Alexandre Lissy
Greg Stoll