This is an editorial change in the ECMA-402 spec. See:
e3f7260
Note the other changes in this commit do not apply to our implementation
as we defer to ICU for the affected steps.
There's a bit of a UTF-8 assumption with this change. But nearly every
caller of these methods were immediately creating a String from the
resulting ByteString anyways.
We know that the payload is always 0 for these three Value types, and so
we can implement checking for them as full 64-bit compares against
constant values instead of checking just the tag.
This avoids shifting the tag 48 bits to the right before comparing it.
Since these are used all over the place, it actually leads to a nice
code size reduction.
By specializing this template and using the special empty JS::Value as a
marker for the `void` state, we shrink this very common class from 16
bytes to 8 bytes.
This allows bytecode instruction handlers to return their result in a
single 64-bit register, allowing tighter code generation.
These were *extremely* hot in profiles (noticed when looking at
disassembly).
Now that we've made the special empty JS::Value much harder to create
accidentally, we can feel better about turning these into ASSERT and
catching them in debug builds.
The special empty value (that we use for array holes, Optional<Value>
when empty and a few other other placeholder/sentinel tasks) still
exists, but you now create one via JS::js_special_empty_value() and
check for it with Value::is_special_empty_value().
The main idea here is to make it very unlikely to accidentally create an
unexpected special empty value.
This patch adds a workaround for a Swift issue where boolean bitfields
with getters and setters in SWIFT_UNSAFE_REFERENCE types are improperly
imported, causing an ICE.
If a class field initializer is just a simple literal, we can skip
creating (and calling) a wrapper function for it entirely.
1.44x speedup on JetStream3/raytrace-private-class-fields.js
1.53x speedup on JetStream3/raytrace-public-class-fields.js
This is the same PRNG used by major browser engines, and although it's
a step down in randomness, it massively improves performance of
Math.random().
1.20x speedup on JetStream3/sync-file-system.js :^)
Instead of returning internal generator results as ordinary JS::Objects
with properties, we now use GeneratorResult and CompletionCell which
both inherit from Cell directly and allow efficient access to state.
1.59x speedup on JetStream3/lazy-collections.js :^)
By moving the LHS and RHS pointers used by rope strings into a
RopeString subclass, we shrink PrimitiveString by 16 bytes. Most strings
are not rope strings, so this ends up saving quite a bit of memory.
Previously, all `GC::Cell` derived classes were Weakable. Marking only
those classes that require this functionality as Weakable allows us to
reduce the memory footprint of some frequently used classes.
PrimitiveString is now internally either UTF-8, UTF-16, or both.
We no longer convert them to/from ByteString anywhere, nor does VM have
a ByteString cache.
If we don't have parameter expressions, we don't need to collect
metadata about whether instantiated var names collide with parameter
names or function names, as these flags are only used in the parameter
code path.
This avoids going through all the shape transitions when setting up the
most common form of ESFO.
This is extremely hot on Uber Eats, and this provides some relief.
Instead of making a copy of the Vector<FunctionParameter> from the AST
every time we instantiate an ECMAScriptFunctionObject, we now keep the
parameters in a ref-counted FunctionParameters object.
This reduces memory usage, and also allows us to cache the bytecode
executables for default parameter expressions without recompiling them
for every instantiation. :^)
The JS runtime is full of checks for is<NumberObject> and friends.
They were showing up in a Speedometer profile as ~1% spent in
dynamic_cast, and this basically chops that down to nothing.
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>
