We should always prefer working with String, and Value::to_string() may
even return a cached String if the Value refers to a primitive string,
but no caching occurs for ByteString.
Previously, `String.prototype.split()` caused the construction of a
temporary StringObject when a string primitive was passed as an
argument, solely to perform a Symbol.split lookup. This change allows
skipping that allocation by looking directly into the prototype of
primitive values.
As a result, we can avoid ~200000 StringObject allocations in a single
test from the Speedometer 2 benchmark.
Co-Authored-By: Andreas Kling <andreas@ladybird.org>
Currently, we create `this_argument` with
`ordinary_create_from_constructor`, then we use `arguments_list` to
build the callee_context.
The issue is we don't properly model the side-effects of
`ordinary_create_from_constructor`, if `new_target` is a proxy object
then when we `get` the prototype, arbitrary javascript can run.
This javascript could perform a function call with enough arguments to
reallocate the interpreters m_argument_values_buffer vector. This is
dangerous and leads to a use-after-free, as our stack frame maintains a
pointer to m_argument_values_buffer (`arguments_list`).
This is a normative change in the ECMA-402 spec. See:
7508197
In our implementation, we don't have the affected AOs directly, as we
delegate to ICU. So instead, we must ensure we provide ICU a locale with
the relevant extension keys present.
This is a normative change in the Temporal proposal. See:
bd5ac12
Note: No test added here because this only affects non-ISO-8601
calendars, which we do not yet support.
This is an editorial change in the Temporal proposal. See:
03770bb
Note: We were actually already using the Temporal definition of this AO
in Intl.DurationFormat, so there's no change needed there.
These are going to be included in the ECMA-262 AOs once Temporal reaches
stage 4. There's no need to keep them in the Temporal namespace. Some
upcoming Temporal editorial changes will get awkward without this patch.
If the regex always matches the input, even if it's past the end, then
we need to stop execution of the regex when it's past the end. This
corresponds to step 13.a and prevents it from infinitely looping.
Reduced from: d98672060f/packages/react-i18n/src/utilities/money.ts (L10-L14)
These properties are always substrings of the RegExp input string,
and so we can store them as views and lazily construct strings if
they're actually accessed (which most of the time they aren't).
This avoids a bunch of unnecessary memory copying, saving roughly
2.1 seconds per iteration of Speedometer.
The promise job's fulfillment / rejection handlers may push an execution
context onto the VM, which will throw an internal error if our ad-hoc
call stack size limit has been reached. Thus, we cannot blindly VERIFY
that the result of invoking these handlers is non-abrupt.
This patch will propagate any internal error forward, and retains the
condition that any other error type is not thrown.
There are now no users of the MUST_OR_THROW_OOM macro. Let's rename this
macro to indicate it may be used to propagate any internal error (such
as the call stack limit error) in places that would otherwise crash due
to a MUST/VERIFY invocation.
Note there's no actual functional change here, as we weren't able to
ensure the internal error was an OOM error previously.
Instead of adding a flag for the two callers that need a pop of the
execution context stack when invoking continue_async_execution inline
the pop of the execution context.
This makes the management of these stacks and surrounding VERIFY calls
much more obvious.
This has no functional difference as run_queued_promise jobs does
nothing when LibWeb is used as it has a different implementation of
enqueuing and running promise jobs. But this change makes it more
obvious that run_queued_promise jobs does nothing when there is an
embedder, and adjusts the comment to reflect what the code is
actually achieving.
In the very common case that no special constructor options are provided
for the Intl.Collator when calling localeCompare() on a string, we can
cache and reuse a default-constructed Intl.Collator, saving lots of time
and space.
This shaves a fair bit of load time off of https://wpt.fyi/ where they
use Array.prototype.sort() and localeCompare() to sort a big JSON thing.
Time spent in sort():
- Before: 1656 ms
- After: 135 ms
Before this change, it was possible for a second GC to get triggered
in the middle of a first GC, due to allocations happening in the
FinalizationRegistry cleanup host hook. To avoid this causing problems,
we add a "post-GC task" mechanism and use that to invoke the host hook
once all other GC activity is finished, and we've unset the "collecting
garbage" flag.
Note that the test included here only fails reliably when running with
the -g flag (collect garbage after each allocation).
Fixes#3051
