Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-19 15:43:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibJS/Runtime/PropertyKey.h

233 lines
6.6 KiB
C
Raw Normal View History

LibJS: Add a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 17:08:23 +02:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02:00
* Copyright (c) 2020, Andreas Kling <andreas@ladybird.org>
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
* Copyright (c) 2025, Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
LibJS: Add a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 17:08:23 +02:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 01:24:48 -07:00
* SPDX-License-Identifier: BSD-2-Clause
LibJS: Add a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 17:08:23 +02:00
*/
#pragma once
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
#include <AK/Utf16FlyString.h>
LibJS: Convert to_string() to ThrowCompletionOr Also update get_function_name() to use ThrowCompletionOr, but this is not a standard AO and should be refactored out of existence eventually.
2021-10-12 17:49:01 +01:00
#include <LibJS/Runtime/Completion.h>
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
#include <LibJS/Runtime/PrimitiveString.h>
#include <LibJS/Runtime/Symbol.h>
LibJS: Add a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 17:08:23 +02:00
namespace JS {
LibJS: Revert Enable EXPLICIT_SYMBOL_EXPORT This reverts commit c14173f651f5a50fdb86beb4b79487454a00f3f6. We should only annotate the minimum number of symbols that external consumers actually use, so I am starting from scratch to do that
2025-07-19 10:41:08 -07:00
class PropertyKey {
LibJS: Stop lazily coercing numeric `PropertyKey`s Lazily coercing might have made sense in the past, but since hashing and comparing requires the `PropertyKey` to be coerced, and since a `PropertyKey` will be used to index into a hashmap 99% of the time, which will hash the `PropertyKey` and use it in comparisons, the extra complexity and branching produced by lazily coercing has become more trouble than it is worth. Remove the lazy coercions, which then also neatly allows us to switch to a `Variant`-based implementation.
2024-12-01 00:37:09 +01:00
public:
LibJS: Avoid lots of string-to-int during global object construction We were doing a *lot* of string-to-int conversion while creating a new global object. This happened because Object::put() would try to convert the property name (string) to an integer to see if it refers to an indexed property. Sidestep this issue by using PropertyName for the CommonPropertyNames struct on VM (vm.names.foo), and giving PropertyName a flag that tells us whether it's a string that *may be* a number. All CommonPropertyNames are set up so they are known to not be numbers.
2021-06-13 18:59:07 +02:00
enum class StringMayBeNumber {
Yes,
No,
};
LibJS: Replace GlobalObject with VM in Value AOs [Part 4/19] This is where the fun begins. :^)
2022-08-21 14:00:56 +01:00
static ThrowCompletionOr<PropertyKey> from_value(VM& vm, Value value)
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
{
LibJS: Make Value() default-construct the undefined value 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.
2025-04-04 23:16:34 +02:00
VERIFY(!value.is_special_empty_value());
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
if (value.is_symbol())
LibJS: Convert PropertyKey::from_value() to ThrowCompletionOr Lots of MUST() - perhaps we'll eventually come up with a better API for the common case where it can't fail.
2022-01-04 22:33:30 +01:00
return PropertyKey { value.as_symbol() };
LibJS: Don't treat 2^32 - 1 as numeric PropertyName 10.4.2 Array Exotic Objects https://tc39.es/ecma262/#sec-array-exotic-objects A String property name P is an array index if and only if ToString(ToUint32(P)) equals P and ToUint32(P) is not the same value as 𝔽(2^32 - 1).
2021-07-06 16:45:54 +01:00
if (value.is_integral_number() && value.as_double() >= 0 && value.as_double() < NumericLimits<u32>::max())
LibJS: Use NaN boxing to decrease the memory size of Values Using the fact that there are 2^52-2 NaN representations we can "NaN-box" all the Values possible. This means that Value no longer has an explicit "Type" but that information is now stored in the bits of a double. This is done by "tagging" the top two bytes of the double. For a full explanation see the large comment with asserts at the top of Value. We can also use the exact representation of the tags to make checking properties like nullish, or is_cell quicker. But the largest gains are in the fact that the size of a Value is now halved. The SunSpider and other benchmarks have been ran to confirm that there are no regressions in performance compared to the previous implementation. The tests never performed worse and in some cases performed better. But the biggest differences can be seen in memory usage when large arrays are allocated. A simple test which allocates a 1000 arrays of size 100000 has roughly half the memory usage. There is also space in the representations for future expansions such as tuples and records. To ensure that Values on the stack and registers are not lost during garbage collection we also have to add a check to the Heap to check for any of the cell tags and extracting the canonical form of the pointer if it matches.
2022-02-25 01:26:52 +01:00
return static_cast<u32>(value.as_double());
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
return TRY(value.to_utf16_string(vm));
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
}
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
static constexpr uintptr_t NORMAL_STRING_FLAG = 0;
static constexpr uintptr_t SHORT_STRING_FLAG = 1;
static constexpr uintptr_t SYMBOL_FLAG = 2;
static constexpr uintptr_t NUMBER_FLAG = 3;
bool is_string() const { return (m_bits & 3) == NORMAL_STRING_FLAG || (m_bits & 3) == SHORT_STRING_FLAG; }
bool is_number() const { return (m_bits & 3) == NUMBER_FLAG; }
bool is_symbol() const { return (m_bits & 3) == SYMBOL_FLAG; }
LibJS: Remove default constructor of `PropertyKey` This constructor was creating an "invalid" `PropertyKey`, but every code path constructing such a `PropertyKey` was either never used or immediately `VERIFY`ing that the `PropertyKey` was valid. The `VERIFY` call has been moved to the `PropertyKey::from_value(...)` call, and the array/object literal spreading code could be refactored to not take a `PropertyKey` but creates dummy values for now. The default constructor for `Reference` has similairly be deleted, because it was never used.
2024-11-01 21:36:48 +01:00
PropertyKey() = delete;
LibJS: Support array holes, encoded as empty JS::Value This patch adds a new kind of JS::Value, the empty value. It's what you get when you do JSValue() (or most commonly, {} in C++.) An empty Value signifies the absence of a value, and should never be visible to JavaScript itself. As of right now, it's used for array holes and as a return value when an exception has been thrown and we just want to unwind. This patch is a bit of a mess as I had to fix a whole bunch of code that was relying on JSValue() being undefined, etc.
2020-04-06 20:24:45 +02:00
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
PropertyKey(PropertyKey const& other)
{
if (other.is_string())
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
new (&m_string) Utf16FlyString(other.m_string);
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
else
m_bits = other.m_bits;
}
PropertyKey(PropertyKey&& other) noexcept
{
if (other.is_string())
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
new (&m_string) Utf16FlyString(move(other.m_string));
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
else
m_bits = exchange(other.m_bits, 0);
}
LibJS: Change PropertyName(i32) => template<Integral T> PropertyName(T) Negative numeric properties are not a thing (and we even VERIFY()'d this in the constructor). It still allows using types with a negative range for now as we have various places using int for example (without actually needing the negative range, but that's a different story). u32 is the internal type of `m_number` already, so this now allows us to leverage the full u32 range for numeric properties.
2021-06-25 18:41:10 +01:00
template<Integral T>
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
PropertyKey(T index)
LibJS: Add a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 17:08:23 +02:00
{
LibJS: Change PropertyName(i32) => template<Integral T> PropertyName(T) Negative numeric properties are not a thing (and we even VERIFY()'d this in the constructor). It still allows using types with a negative range for now as we have various places using int for example (without actually needing the negative range, but that's a different story). u32 is the internal type of `m_number` already, so this now allows us to leverage the full u32 range for numeric properties.
2021-06-25 18:41:10 +01:00
// FIXME: Replace this with requires(IsUnsigned<T>)?
// Needs changes in various places using `int` (but not actually being in the negative range)
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(index >= 0);
LibJS: Add a way of constructing PropertyName with values above 2**32-1 This is often needed in ArrayPrototype when getting items with indices above 2**32-1 is possible since length is at most 2**53-1. This also fixes a number of these cases in ArrayPrototype where the type was not big enough to hold the potential values.
2021-07-07 14:17:51 +02:00
if constexpr (NumericLimits<T>::max() >= NumericLimits<u32>::max()) {
if (index >= NumericLimits<u32>::max()) {
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
new (&m_string) Utf16FlyString { Utf16String::number(index) };
LibJS: Add a way of constructing PropertyName with values above 2**32-1 This is often needed in ArrayPrototype when getting items with indices above 2**32-1 is possible since length is at most 2**53-1. This also fixes a number of these cases in ArrayPrototype where the type was not big enough to hold the potential values.
2021-07-07 14:17:51 +02:00
return;
}
}
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
m_number = static_cast<u64>(index) << 2 | NUMBER_FLAG;
LibJS: Add a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 17:08:23 +02:00
}
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
PropertyKey(Utf16FlyString string, StringMayBeNumber string_may_be_number = StringMayBeNumber::Yes)
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
{
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
if (string_may_be_number == StringMayBeNumber::Yes) {
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
if (!string.is_empty() && !(string.code_unit_at(0) == '0' && string.length_in_code_units() > 1)) {
auto property_index = string.to_number<u32>(TrimWhitespace::No);
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
if (property_index.has_value() && property_index.value() < NumericLimits<u32>::max()) {
m_number = static_cast<u64>(property_index.release_value()) << 2 | NUMBER_FLAG;
return;
}
}
}
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
new (&m_string) Utf16FlyString(move(string));
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
}
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
PropertyKey(Utf16String const& string)
: PropertyKey(Utf16FlyString { string })
LibJS: Add a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 17:08:23 +02:00
{
}
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
PropertyKey(GC::Ref<Symbol> symbol)
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
{
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
m_bits = reinterpret_cast<uintptr_t>(symbol.ptr()) | SYMBOL_FLAG;
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
}
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
PropertyKey& operator=(PropertyKey const& other)
{
if (this != &other) {
if (is_string())
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
m_string.~Utf16FlyString();
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
new (this) PropertyKey(other);
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
}
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
return *this;
}
PropertyKey& operator=(PropertyKey&& other) noexcept
LibJS: Automatically & lazily coerce PropertyNames into numbers This commit expands on 5eef07d232fc179f0640bbb8cff575cd239c4d65 by automatically trying to coerce Type::String PropertyNames into numbers when a caller checks if the PropertyName is_number/is_string. This has several benefits: - We no longer have to duplicate the number coercion code to every function that accepts a PropertyNumber. (Or more likely, forget to.) - This keeps the lazy nature of only doing the coercion when and if there is a semantic difference to the different PropertyName types, which means this shouldnt cause any performance drop. - Since this coercion changes the state of the PropertyName itself the result is essentially cached and can speed up any repeat uses of the same PropertyName instance.
2021-06-16 20:51:07 +03:00
{
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
if (this != &other) {
if (is_string())
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
m_string.~Utf16FlyString();
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
new (this) PropertyKey(move(other));
}
return *this;
LibJS: Automatically & lazily coerce PropertyNames into numbers This commit expands on 5eef07d232fc179f0640bbb8cff575cd239c4d65 by automatically trying to coerce Type::String PropertyNames into numbers when a caller checks if the PropertyName is_number/is_string. This has several benefits: - We no longer have to duplicate the number coercion code to every function that accepts a PropertyNumber. (Or more likely, forget to.) - This keeps the lazy nature of only doing the coercion when and if there is a semantic difference to the different PropertyName types, which means this shouldnt cause any performance drop. - Since this coercion changes the state of the PropertyName itself the result is essentially cached and can speed up any repeat uses of the same PropertyName instance.
2021-06-16 20:51:07 +03:00
}
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
~PropertyKey()
{
if (is_string())
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
m_string.~Utf16FlyString();
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
}
LibJS: Automatically & lazily coerce PropertyNames into numbers This commit expands on 5eef07d232fc179f0640bbb8cff575cd239c4d65 by automatically trying to coerce Type::String PropertyNames into numbers when a caller checks if the PropertyName is_number/is_string. This has several benefits: - We no longer have to duplicate the number coercion code to every function that accepts a PropertyNumber. (Or more likely, forget to.) - This keeps the lazy nature of only doing the coercion when and if there is a semantic difference to the different PropertyName types, which means this shouldnt cause any performance drop. - Since this coercion changes the state of the PropertyName itself the result is essentially cached and can speed up any repeat uses of the same PropertyName instance.
2021-06-16 20:51:07 +03:00
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
u32 as_number() const
{
VERIFY(is_number());
return m_number >> 2;
}
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
Utf16FlyString const& as_string() const
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
{
VERIFY(is_string());
return m_string;
}
Symbol const* as_symbol() const
{
VERIFY(is_symbol());
return reinterpret_cast<Symbol const*>(m_bits & ~3ULL);
}
Value to_value(VM& vm) const
{
if (is_string())
return Value { PrimitiveString::create(vm, as_string()) };
if (is_symbol())
return Value { as_symbol() };
LibJS: Add number-to-string cache for numbers < 1000 We are often forced to convert numbers to strings inside LibJS, e.g when iterating over the property names of an array, but it's also just a very common operation in general. This patch adds a 1000-entry string cache for the numbers 0-999 since those appear to be by far the most common ones we convert.
2025-10-04 11:00:20 +02:00
return Value { PrimitiveString::create_from_unsigned_integer(vm, as_number()) };
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
}
LibJS: Add a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 17:08:23 +02:00
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
Utf16String to_string() const
LibJS: Add Reference class to represent a base.property reference Expression nodes can now be asked to produce a Reference. We then use this to implement the "delete" operator without downcasting the child node to a MemberExpression manually.
2020-04-27 12:10:16 +02:00
{
if (is_string())
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
return as_string().to_utf16_string();
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
if (is_symbol())
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
return as_symbol()->descriptive_string();
return Utf16String::number(as_number());
LibJS: Add Reference class to represent a base.property reference Expression nodes can now be asked to produce a Reference. We then use this to implement the "delete" operator without downcasting the child node to a MemberExpression manually.
2020-04-27 12:10:16 +02:00
}
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
void visit_edges(Cell::Visitor& visitor) const
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
{
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
if (is_symbol())
visitor.visit(const_cast<Symbol*>(as_symbol()));
LibJS: Integrate Symbols into objects as valid keys This allows objects properties to be created for symbol keys in addition to just plain strings/numbers
2020-07-07 21:38:46 -07:00
}
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
bool operator==(PropertyKey const& other) const
LibJS: Stop lazily coercing numeric `PropertyKey`s Lazily coercing might have made sense in the past, but since hashing and comparing requires the `PropertyKey` to be coerced, and since a `PropertyKey` will be used to index into a hashmap 99% of the time, which will hash the `PropertyKey` and use it in comparisons, the extra complexity and branching produced by lazily coercing has become more trouble than it is worth. Remove the lazy coercions, which then also neatly allows us to switch to a `Variant`-based implementation.
2024-12-01 00:37:09 +01:00
{
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
if (is_string())
return other.is_string() && m_string == other.m_string;
if (is_symbol())
return other.is_symbol() && as_symbol() == other.as_symbol();
if (other.is_number())
return as_number() == other.as_number();
return false;
LibJS: Stop lazily coercing numeric `PropertyKey`s Lazily coercing might have made sense in the past, but since hashing and comparing requires the `PropertyKey` to be coerced, and since a `PropertyKey` will be used to index into a hashmap 99% of the time, which will hash the `PropertyKey` and use it in comparisons, the extra complexity and branching produced by lazily coercing has become more trouble than it is worth. Remove the lazy coercions, which then also neatly allows us to switch to a `Variant`-based implementation.
2024-12-01 00:37:09 +01:00
}
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
private:
friend Traits<PropertyKey>;
union {
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
Utf16FlyString m_string;
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
u64 m_number;
Symbol const* m_symbol;
uintptr_t m_bits;
};
LibJS: Add a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 17:08:23 +02:00
};
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
static_assert(sizeof(PropertyKey) == sizeof(uintptr_t));
LibJS: Provide default hash traits for JS::PropertyKey Let's not require people to use PropertyNameTraits everywhere when we can just specialize AK::Traits<JS::PropertyKey> instead. :^)
2021-10-24 16:19:28 +02:00
}
namespace AK {
template<>
AK: Rename GenericTraits to DefaultTraits This feels like a more fitting name for something that provides the default values for Traits.
2023-11-08 20:29:12 +01:00
struct Traits<JS::PropertyKey> : public DefaultTraits<JS::PropertyKey> {
LibJS: Provide default hash traits for JS::PropertyKey Let's not require people to use PropertyNameTraits everywhere when we can just specialize AK::Traits<JS::PropertyKey> instead. :^)
2021-10-24 16:19:28 +02:00
static unsigned hash(JS::PropertyKey const& name)
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
{
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
if (name.is_string())
return name.as_string().hash();
if (name.is_symbol())
return ptr_hash(name.as_symbol());
if (name.is_number())
return int_hash(name.as_number());
VERIFY_NOT_REACHED();
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
}
LibJS: Provide default hash traits for JS::PropertyKey Let's not require people to use PropertyNameTraits everywhere when we can just specialize AK::Traits<JS::PropertyKey> instead. :^)
2021-10-24 16:19:28 +02:00
static bool equals(JS::PropertyKey const& a, JS::PropertyKey const& b)
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
{
LibJS+LibWeb: Replace StringOrSymbol usage with PropertyKey - Avoids unnecessary conversions between StringOrSymbol and PropertyKey on the hot path of property access. - Simplifies the code by removing StringOrSymbol and using PropertyKey directly. There was no reason to have a separate StringOrSymbol type representing the same data as PropertyKey, just with the index key stored as a string. PropertyKey has been updated to use a tagged pointer instead of a Variant, so it still occupies 8 bytes, same as StringOrSymbol. 12% improvement on JetStream/gcc-loops.cpp.js 12% improvement on MicroBench/object-assign.js 7% improvement on MicroBench/object-keys.js
2025-05-15 17:14:00 +03:00
if (a.is_string())
return b.is_string() && a.as_string() == b.as_string();
if (a.is_symbol())
return b.is_symbol() && a.as_symbol() == b.as_symbol();
if (a.is_number())
return b.is_number() && a.as_number() == b.as_number();
VERIFY_NOT_REACHED();
LibJS: Restructure and fully implement BindingPatterns
2021-06-12 18:04:28 -07:00
}
};
LibJS: Avoid lots of string-to-int during global object construction We were doing a *lot* of string-to-int conversion while creating a new global object. This happened because Object::put() would try to convert the property name (string) to an integer to see if it refers to an indexed property. Sidestep this issue by using PropertyName for the CommonPropertyNames struct on VM (vm.names.foo), and giving PropertyName a flag that tells us whether it's a string that *may be* a number. All CommonPropertyNames are set up so they are known to not be numbers.
2021-06-13 18:59:07 +02:00
template<>
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
struct Formatter<JS::PropertyKey> : Formatter<Utf16String> {
Everywhere: Rename JS::PropertyKey variables from property_{name => key} PropertyKey used to be called PropertyName, but got renamed. Let's update all the variables of this type as well.
2022-02-06 15:59:04 +00:00
ErrorOr<void> format(FormatBuilder& builder, JS::PropertyKey const& property_key)
LibJS: Handle invalid and symbol PropertyName in its AK::Formatter This would previously crash as we used to_string() without checking the type first. Circumvent that by handling invalid and numeric ones separately and then using to_string_or_symbol().
2021-07-04 17:59:07 +01:00
{
Everywhere: Rename JS::PropertyKey variables from property_{name => key} PropertyKey used to be called PropertyName, but got renamed. Let's update all the variables of this type as well.
2022-02-06 15:59:04 +00:00
if (property_key.is_number())
Meta+Userland: Simplify some formatters These are mostly minor mistakes I've encountered while working on the removal of StringView(char const*). The usage of builder.put_string over Format<FormatString>::format is preferrable as it will avoid the indirection altogether when there's no formatting to be done. Similarly, there is no need to do format(builder, "{}", number) when builder.put_u64(number) works equally well. Additionally a few Strings where only constant strings were used are replaced with StringViews.
2022-07-11 20:23:24 +00:00
return builder.put_u64(property_key.as_number());
LibJS+LibWeb+WebContent: Port JS::PropertyKey to UTF-16 This has quite a lot of fall out. But the majority of it is just type or UDL substitution, where the changes just fall through to other function calls. By changing property key storage to UTF-16, the main affected areas are: * NativeFunction names must now be UTF-16 * Bytecode identifiers must now be UTF-16 * Module/binding names must now be UTF-16
2025-08-02 19:27:29 -04:00
return Formatter<Utf16String>::format(builder, property_key.to_string());
LibJS: Avoid lots of string-to-int during global object construction We were doing a *lot* of string-to-int conversion while creating a new global object. This happened because Object::put() would try to convert the property name (string) to an integer to see if it refers to an indexed property. Sidestep this issue by using PropertyName for the CommonPropertyNames struct on VM (vm.names.foo), and giving PropertyName a flag that tells us whether it's a string that *may be* a number. All CommonPropertyNames are set up so they are known to not be numbers.
2021-06-13 18:59:07 +02:00
}
};
}
Reference in a new issue Copy permalink