Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-04 07:10:57 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibJS/Runtime/Value.h

659 lines
22 KiB
C
Raw Normal View History

LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
/*
LibJS: Split Value::Type::Number into Int32 and Double We now store 32-bit integers as 32-bit integers directly which avoids having to convert them from doubles when they're only used as 32-bit integers anyway. :^) This patch feels a bit incomplete and there's a lot of opportunities to take advantage of this information. We'll have to find and exploit them eventually.
2021-03-21 18:03:00 +01:00
* Copyright (c) 2020-2021, Andreas Kling <kling@serenityos.org>
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
* Copyright (c) 2020-2022, Linus Groh <linusg@serenityos.org>
LibJS: Use __builtin_isnan in static_assert instead of isnan For the fuzzer build isnan was not usable in a constexpr context however __builtin_isnan seems to always be. Also while we're here add my name to the copyright since I forgot after the Value rewrite.
2022-08-23 20:24:59 +02:00
* Copyright (c) 2022, David Tuin <davidot@serenityos.org>
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01: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: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
*/
#pragma once
#include <AK/Assertions.h>
LibJS: Simplify positive/negative zero checks Because both zeroes have unique and distinct bit representations, we can bit_cast value to u64 and check if it's one of them.
2021-03-22 21:26:16 +03:00
#include <AK/BitCast.h>
LibJS: Prevent implicit pointer-to-bool conversion in Value constructor For example, say you try to create a Value from an Array and forgot to include LibJS/Runtime/Array.h. This would cause the boolean constructor to be used instead of a compile error.
2022-01-27 07:45:00 -05:00
#include <AK/Concepts.h>
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
#include <AK/Format.h>
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
#include <AK/Forward.h>
LibJS: Implement the CreateListFromArrayLike() abstract operation We already have two separate implementations of this, so let's do it properly. The optional value type check is done by a callback function that returns Result<void, ErrorType> - value type accepted or message for TypeError, that is.
2021-06-09 23:27:01 +01:00
#include <AK/Function.h>
#include <AK/Result.h>
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
#include <AK/String.h>
LibJS: Implement standard semantics for relational operators (#2417) Previously, the relational operators where casting any value to double and comparing the results according to C++ semantics. This patch makes the relational operators in JS behave according to the standard specification. Since we don't have BigInt yet, the implementation doesn't take it into account. Moved PreferredType from Object to Value. Value::to_primitive now passes preferred_type to Object::to_primitive.
2020-05-28 17:19:59 +02:00
#include <AK/Types.h>
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
#include <LibJS/Forward.h>
LibJS: Move ValueTraits to Value.h and add special case for -0.0 This will allow us to use these traits for other hash-based containers (like Map). This commit also adds a special case for negative zero values, because while the equality check used same_value_zero which is negative/positive zero insensitive, the hash was not.
2021-06-12 23:15:19 +03:00
#include <LibJS/Runtime/BigInt.h>
LibJS: Replace Vector<u16> usage in PrimitiveString wth Utf16String This commit does not go out of its way to reduce copying of the string data yet, but is a minimum set of changes to compile LibJS after making PrimitiveString hold a Utf16String.
2021-08-09 09:06:45 -04:00
#include <LibJS/Runtime/Utf16String.h>
LibM: Add NAN macro
2020-06-04 13:03:15 +01:00
#include <math.h>
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
LibJS: Make Array.prototype.push() generic
2020-05-22 13:20:53 +01:00
// 2 ** 53 - 1
static constexpr double MAX_ARRAY_LIKE_INDEX = 9007199254740991.0;
LibJS: Simplify positive/negative zero checks Because both zeroes have unique and distinct bit representations, we can bit_cast value to u64 and check if it's one of them.
2021-03-22 21:26:16 +03:00
// Unique bit representation of negative zero (only sign bit set)
static constexpr u64 NEGATIVE_ZERO_BITS = ((u64)1 << 63);
LibJS: Make Array.prototype.push() generic
2020-05-22 13:20:53 +01:00
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
namespace JS {
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
static_assert(sizeof(double) == 8);
static_assert(sizeof(void*) == sizeof(double) || sizeof(void*) == sizeof(u32));
// To make our Value representation compact we can use the fact that IEEE
// doubles have a lot (2^52 - 2) of NaN bit patterns. The canonical form being
// just 0x7FF8000000000000 i.e. sign = 0 exponent is all ones and the top most
// bit of the mantissa set.
static constexpr u64 CANON_NAN_BITS = bit_cast<u64>(__builtin_nan(""));
static_assert(CANON_NAN_BITS == 0x7FF8000000000000);
// (Unfortunately all the other values are valid so we have to convert any
// incoming NaNs to this pattern although in practice it seems only the negative
// version of these CANON_NAN_BITS)
// +/- Infinity are represented by a full exponent but without any bits of the
// mantissa set.
static constexpr u64 POSITIVE_INFINITY_BITS = bit_cast<u64>(__builtin_huge_val());
static constexpr u64 NEGATIVE_INFINITY_BITS = bit_cast<u64>(-__builtin_huge_val());
static_assert(POSITIVE_INFINITY_BITS == 0x7FF0000000000000);
static_assert(NEGATIVE_INFINITY_BITS == 0xFFF0000000000000);
// However as long as any bit is set in the mantissa with the exponent of all
// ones this value is a NaN, and it even ignores the sign bit.
LibJS: Use __builtin_isnan in static_assert instead of isnan For the fuzzer build isnan was not usable in a constexpr context however __builtin_isnan seems to always be. Also while we're here add my name to the copyright since I forgot after the Value rewrite.
2022-08-23 20:24:59 +02:00
// (NOTE: we have to use __builtin_isnan here since some isnan implementations are not constexpr)
static_assert(__builtin_isnan(bit_cast<double>(0x7FF0000000000001)));
static_assert(__builtin_isnan(bit_cast<double>(0xFFF0000000040000)));
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
// This means we can use all of these NaNs to store all other options for Value.
// To make sure all of these other representations we use 0x7FF8 as the base top
// 2 bytes which ensures the value is always a NaN.
static constexpr u64 BASE_TAG = 0x7FF8;
// This leaves the sign bit and the three lower bits for tagging a value and then
// 48 bits of potential payload.
// First the pointer backed types (Object, String etc.), to signify this category
// and make stack scanning easier we use the sign bit (top most bit) of 1 to
// signify that it is a pointer backed type.
static constexpr u64 IS_CELL_BIT = 0x8000 | BASE_TAG;
// On all current 64-bit systems this code runs pointer actually only use the
// lowest 6 bytes which fits neatly into our NaN payload with the top two bytes
// left over for marking it as a NaN and tagging the type.
// Note that we do need to take care when extracting the pointer value but this
// is explained in the extract_pointer method.
// This leaves us 3 bits to tag the type of pointer:
static constexpr u64 OBJECT_TAG = 0b001 | IS_CELL_BIT;
static constexpr u64 STRING_TAG = 0b010 | IS_CELL_BIT;
static constexpr u64 SYMBOL_TAG = 0b011 | IS_CELL_BIT;
static constexpr u64 ACCESSOR_TAG = 0b100 | IS_CELL_BIT;
static constexpr u64 BIGINT_TAG = 0b101 | IS_CELL_BIT;
// We can then by extracting the top 13 bits quickly check if a Value is
// pointer backed.
static constexpr u64 IS_CELL_PATTERN = 0xFFF8ULL;
static_assert((OBJECT_TAG & IS_CELL_PATTERN) == IS_CELL_PATTERN);
static_assert((STRING_TAG & IS_CELL_PATTERN) == IS_CELL_PATTERN);
static_assert((CANON_NAN_BITS & IS_CELL_PATTERN) != IS_CELL_PATTERN);
static_assert((NEGATIVE_INFINITY_BITS & IS_CELL_PATTERN) != IS_CELL_PATTERN);
// Then for the non pointer backed types we don't set the sign bit and use the
// three lower bits for tagging as well.
static constexpr u64 UNDEFINED_TAG = 0b110 | BASE_TAG;
static constexpr u64 NULL_TAG = 0b111 | BASE_TAG;
static constexpr u64 BOOLEAN_TAG = 0b001 | BASE_TAG;
static constexpr u64 INT32_TAG = 0b010 | BASE_TAG;
static constexpr u64 EMPTY_TAG = 0b011 | BASE_TAG;
// Notice how only undefined and null have the top bit set, this mean we can
// quickly check for nullish values by checking if the top and bottom bits are set
// but the middle one isn't.
static constexpr u64 IS_NULLISH_EXTRACT_PATTERN = 0xFFFEULL;
static constexpr u64 IS_NULLISH_PATTERN = 0x7FFEULL;
static_assert((UNDEFINED_TAG & IS_NULLISH_EXTRACT_PATTERN) == IS_NULLISH_PATTERN);
static_assert((NULL_TAG & IS_NULLISH_EXTRACT_PATTERN) == IS_NULLISH_PATTERN);
static_assert((BOOLEAN_TAG & IS_NULLISH_EXTRACT_PATTERN) != IS_NULLISH_PATTERN);
static_assert((INT32_TAG & IS_NULLISH_EXTRACT_PATTERN) != IS_NULLISH_PATTERN);
static_assert((EMPTY_TAG & IS_NULLISH_EXTRACT_PATTERN) != IS_NULLISH_PATTERN);
// We also have the empty tag to represent array holes however since empty
// values are not valid anywhere else we can use this "value" to our advantage
// in Optional<Value> to represent the empty optional.
static constexpr u64 TAG_EXTRACTION = 0xFFFF000000000000;
static constexpr u64 TAG_SHIFT = 48;
static constexpr u64 SHIFTED_INT32_TAG = INT32_TAG << TAG_SHIFT;
static constexpr u64 SHIFTED_IS_CELL_PATTERN = IS_CELL_PATTERN << TAG_SHIFT;
// Summary:
// To pack all the different value in to doubles we use the following schema:
// s = sign, e = exponent, m = mantissa
// The top part is the tag and the bottom the payload.
// 0bseeeeeeeeeeemmmm mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
// 0b0111111111111000 0... is the only real NaN
// 0b1111111111111xxx yyy... xxx = pointer type, yyy = pointer value
// 0b0111111111111xxx yyy... xxx = non-pointer type, yyy = value or 0 if just type
// Future expansion: We are not fully utilizing all the possible bit patterns
// yet, these choices were made to make it easy to implement and understand.
// We can for example drop the always 1 top bit of the mantissa expanding our
// options from 8 tags to 15 but since we currently only use 5 for both sign bits
// this is not needed.
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
class Value {
public:
LibJS: Implement standard semantics for relational operators (#2417) Previously, the relational operators where casting any value to double and comparing the results according to C++ semantics. This patch makes the relational operators in JS behave according to the standard specification. Since we don't have BigInt yet, the implementation doesn't take it into account. Moved PreferredType from Object to Value. Value::to_primitive now passes preferred_type to Object::to_primitive.
2020-05-28 17:19:59 +02:00
enum class PreferredType {
Default,
String,
Number,
};
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
bool is_empty() const { return m_value.tag == EMPTY_TAG; }
bool is_undefined() const { return m_value.tag == UNDEFINED_TAG; }
bool is_null() const { return m_value.tag == NULL_TAG; }
bool is_number() const { return is_double() || is_int32(); }
bool is_string() const { return m_value.tag == STRING_TAG; }
bool is_object() const { return m_value.tag == OBJECT_TAG; }
bool is_boolean() const { return m_value.tag == BOOLEAN_TAG; }
bool is_symbol() const { return m_value.tag == SYMBOL_TAG; }
bool is_accessor() const { return m_value.tag == ACCESSOR_TAG; };
bool is_bigint() const { return m_value.tag == BIGINT_TAG; };
bool is_nullish() const { return (m_value.tag & IS_NULLISH_EXTRACT_PATTERN) == IS_NULLISH_PATTERN; }
bool is_cell() const { return (m_value.tag & IS_CELL_PATTERN) == IS_CELL_PATTERN; }
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
ThrowCompletionOr<bool> is_array(VM&) const;
LibJS: Add Value::{is, as}_function()
2020-05-06 11:52:53 +01:00
bool is_function() const;
LibJS: Add initial support for Promises Almost a year after first working on this, it's finally done: an implementation of Promises for LibJS! :^) The core functionality is working and closely following the spec [1]. I mostly took the pseudo code and transformed it into C++ - if you read and understand it, you will know how the spec implements Promises; and if you read the spec first, the code will look very familiar. Implemented functions are: - Promise() constructor - Promise.prototype.then() - Promise.prototype.catch() - Promise.prototype.finally() - Promise.resolve() - Promise.reject() For the tests I added a new function to test-js's global object, runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs(). By design, queued jobs normally only run after the script was fully executed, making it improssible to test handlers in individual test() calls by default [2]. Subsequent commits include integrations into LibWeb and js(1) - pretty-printing, running queued promise jobs when necessary. This has an unusual amount of dbgln() statements, all hidden behind the PROMISE_DEBUG flag - I'm leaving them in for now as they've been very useful while debugging this, things can get quite complex with so many asynchronously executed functions. I've not extensively explored use of these APIs for promise-based functionality in LibWeb (fetch(), Notification.requestPermission() etc.), but we'll get there in due time. [1]: https://tc39.es/ecma262/#sec-promise-objects [2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
2021-04-01 22:13:29 +02:00
bool is_constructor() const;
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
ThrowCompletionOr<bool> is_regexp(VM&) const;
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
LibJS: Take advantage of Value::Type::Int32 in a bunch of functions If a JS::Value has type Int32, we know it's a finite, 32-bit integer. Use this information to avoid converting it to a double if possible.
2021-10-07 19:23:56 +02:00
bool is_nan() const
{
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 m_value.encoded == CANON_NAN_BITS;
LibJS: Take advantage of Value::Type::Int32 in a bunch of functions If a JS::Value has type Int32, we know it's a finite, 32-bit integer. Use this information to avoid converting it to a double if possible.
2021-10-07 19:23:56 +02:00
}
bool is_infinity() const
{
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
static_assert(NEGATIVE_INFINITY_BITS == (0x1ULL << 63 | POSITIVE_INFINITY_BITS));
return (0x1ULL << 63 | m_value.encoded) == NEGATIVE_INFINITY_BITS;
LibJS: Take advantage of Value::Type::Int32 in a bunch of functions If a JS::Value has type Int32, we know it's a finite, 32-bit integer. Use this information to avoid converting it to a double if possible.
2021-10-07 19:23:56 +02:00
}
bool is_positive_infinity() const
{
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 m_value.encoded == POSITIVE_INFINITY_BITS;
LibJS: Take advantage of Value::Type::Int32 in a bunch of functions If a JS::Value has type Int32, we know it's a finite, 32-bit integer. Use this information to avoid converting it to a double if possible.
2021-10-07 19:23:56 +02:00
}
bool is_negative_infinity() const
{
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 m_value.encoded == NEGATIVE_INFINITY_BITS;
LibJS: Take advantage of Value::Type::Int32 in a bunch of functions If a JS::Value has type Int32, we know it's a finite, 32-bit integer. Use this information to avoid converting it to a double if possible.
2021-10-07 19:23:56 +02:00
}
bool is_positive_zero() const
{
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 m_value.encoded == 0 || (is_int32() && as_i32() == 0);
LibJS: Take advantage of Value::Type::Int32 in a bunch of functions If a JS::Value has type Int32, we know it's a finite, 32-bit integer. Use this information to avoid converting it to a double if possible.
2021-10-07 19:23:56 +02:00
}
bool is_negative_zero() const
{
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 m_value.encoded == NEGATIVE_ZERO_BITS;
LibJS: Take advantage of Value::Type::Int32 in a bunch of functions If a JS::Value has type Int32, we know it's a finite, 32-bit integer. Use this information to avoid converting it to a double if possible.
2021-10-07 19:23:56 +02:00
}
bool is_integral_number() const
{
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
if (is_int32())
LibJS: Take advantage of Value::Type::Int32 in a bunch of functions If a JS::Value has type Int32, we know it's a finite, 32-bit integer. Use this information to avoid converting it to a double if possible.
2021-10-07 19:23:56 +02:00
return true;
return is_finite_number() && trunc(as_double()) == as_double();
}
LibJS: Implement bitwise left shift operator (<<)
2020-04-23 13:36:14 +01:00
bool is_finite_number() const
{
if (!is_number())
return false;
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
if (is_int32())
return true;
return !is_nan() && !is_infinity();
LibJS: Implement bitwise left shift operator (<<)
2020-04-23 13:36:14 +01:00
}
LibJS: Basic NaN support This patch adds js_nan() for constructing a NaN value. You can check if a Value is NaN with Value::is_nan().
2020-03-27 12:26:37 +01:00
LibJS: Inline JS::Value() I had this out of line for debugging reasons. Put it back inline.
2020-04-06 20:30:36 +02:00
Value()
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
: Value(EMPTY_TAG << TAG_SHIFT, (u64)0)
LibJS: Inline JS::Value() I had this out of line for debugging reasons. Put it back inline.
2020-04-06 20:30:36 +02:00
{
}
LibJS: Allow default-constructing a JS::Value (undefined)
2020-03-20 20:49:48 +01:00
LibJS: Prevent implicit pointer-to-bool conversion in Value constructor For example, say you try to create a Value from an Array and forgot to include LibJS/Runtime/Array.h. This would cause the boolean constructor to be used instead of a compile error.
2022-01-27 07:45:00 -05:00
template<typename T>
LibJS: Use a template for 'Value from integral number' constructors This also allows constructing from other integral types like u64, which would have been ambiguous before (at least on i686): ``` error: call of overloaded 'Value(u64&)' is ambiguous note: candidate: 'JS::Value::Value(i32)' 175 | explicit Value(i32 value) | ^~~~~ note: candidate: 'JS::Value::Value(unsigned int)' 164 | explicit Value(unsigned value) | ^~~~~ note: candidate: 'JS::Value::Value(long unsigned int)' 153 | explicit Value(unsigned long value) | ^~~~~ note: candidate: 'JS::Value::Value(double)' 141 | explicit Value(double value) | ^~~~~ ```
2022-07-03 16:55:32 +02:00
requires(IsSameIgnoringCV<T, bool>) explicit Value(T value)
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
: Value(BOOLEAN_TAG << TAG_SHIFT, (u64)value)
LibJS: Flesh out JS::Value a little bit more
2020-03-07 23:16:14 +01:00
{
}
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
explicit Value(double value)
{
LibJS: Simplify positive/negative zero checks Because both zeroes have unique and distinct bit representations, we can bit_cast value to u64 and check if it's one of them.
2021-03-22 21:26:16 +03:00
bool is_negative_zero = bit_cast<u64>(value) == NEGATIVE_ZERO_BITS;
LibJS: *Actually* check for negative zero in JS::Value(double) As @nico pointed out, 0.0 == -0.0 in C++, even though they are not bitwise identical. Use the same trick as Value::is_negative_zero() to really check for it. This allows JS::Value(0.0) to correctly become an Int32-backed 0 value.
2021-03-22 07:49:08 +01:00
if (value >= NumericLimits<i32>::min() && value <= NumericLimits<i32>::max() && trunc(value) == value && !is_negative_zero) {
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
VERIFY(!(SHIFTED_INT32_TAG & (static_cast<i32>(value) & 0xFFFFFFFFul)));
m_value.encoded = SHIFTED_INT32_TAG | (static_cast<i32>(value) & 0xFFFFFFFFul);
LibJS: Split Value::Type::Number into Int32 and Double We now store 32-bit integers as 32-bit integers directly which avoids having to convert them from doubles when they're only used as 32-bit integers anyway. :^) This patch feels a bit incomplete and there's a lot of opportunities to take advantage of this information. We'll have to find and exploit them eventually.
2021-03-21 18:03:00 +01:00
} else {
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
if (isnan(value)) [[unlikely]]
m_value.encoded = CANON_NAN_BITS;
else
m_value.as_double = value;
LibJS: Split Value::Type::Number into Int32 and Double We now store 32-bit integers as 32-bit integers directly which avoids having to convert them from doubles when they're only used as 32-bit integers anyway. :^) This patch feels a bit incomplete and there's a lot of opportunities to take advantage of this information. We'll have to find and exploit them eventually.
2021-03-21 18:03:00 +01:00
}
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
}
LibJS: Use a template for 'Value from integral number' constructors This also allows constructing from other integral types like u64, which would have been ambiguous before (at least on i686): ``` error: call of overloaded 'Value(u64&)' is ambiguous note: candidate: 'JS::Value::Value(i32)' 175 | explicit Value(i32 value) | ^~~~~ note: candidate: 'JS::Value::Value(unsigned int)' 164 | explicit Value(unsigned value) | ^~~~~ note: candidate: 'JS::Value::Value(long unsigned int)' 153 | explicit Value(unsigned long value) | ^~~~~ note: candidate: 'JS::Value::Value(double)' 141 | explicit Value(double value) | ^~~~~ ```
2022-07-03 16:55:32 +02:00
// NOTE: A couple of integral types are excluded here:
// - i32 has its own dedicated Value constructor
// - i64 cannot safely be cast to a double
// - bool isn't a number type and has its own dedicated Value constructor
template<typename T>
requires(IsIntegral<T> && !IsSameIgnoringCV<T, i32> && !IsSameIgnoringCV<T, i64> && !IsSameIgnoringCV<T, bool>) explicit Value(T value)
LibJS: Implement bitwise unsigned right shift operator (>>>)
2020-04-23 15:43:10 +01:00
{
LibJS: Split Value::Type::Number into Int32 and Double We now store 32-bit integers as 32-bit integers directly which avoids having to convert them from doubles when they're only used as 32-bit integers anyway. :^) This patch feels a bit incomplete and there's a lot of opportunities to take advantage of this information. We'll have to find and exploit them eventually.
2021-03-21 18:03:00 +01:00
if (value > NumericLimits<i32>::max()) {
m_value.as_double = static_cast<double>(value);
} else {
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
VERIFY(!(SHIFTED_INT32_TAG & (static_cast<i32>(value) & 0xFFFFFFFFul)));
m_value.encoded = SHIFTED_INT32_TAG | (static_cast<i32>(value) & 0xFFFFFFFFul);
}
}
explicit Value(unsigned value)
{
if (value > NumericLimits<i32>::max()) {
m_value.as_double = static_cast<double>(value);
} else {
VERIFY(!(SHIFTED_INT32_TAG & (static_cast<i32>(value) & 0xFFFFFFFFul)));
m_value.encoded = SHIFTED_INT32_TAG | (static_cast<i32>(value) & 0xFFFFFFFFul);
LibJS: Split Value::Type::Number into Int32 and Double We now store 32-bit integers as 32-bit integers directly which avoids having to convert them from doubles when they're only used as 32-bit integers anyway. :^) This patch feels a bit incomplete and there's a lot of opportunities to take advantage of this information. We'll have to find and exploit them eventually.
2021-03-21 18:03:00 +01:00
}
LibJS: Implement bitwise unsigned right shift operator (>>>)
2020-04-23 15:43:10 +01:00
}
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
explicit Value(i32 value)
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
: Value(SHIFTED_INT32_TAG, (u32)value)
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
{
}
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
Value(Object const* object)
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
: Value(object ? (OBJECT_TAG << TAG_SHIFT) : (NULL_TAG << TAG_SHIFT), reinterpret_cast<void const*>(object))
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
{
}
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
Value(PrimitiveString const* string)
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
: Value(STRING_TAG << TAG_SHIFT, reinterpret_cast<void const*>(string))
LibJS: Support "hello friends".length The above snippet is a MemberExpression that necessitates the implicit construction of a StringObject wrapper around a PrimitiveString. We then do a property lookup (a "get") on the StringObject, where we find the "length" property. This is pretty neat! :^)
2020-03-11 18:58:19 +01:00
{
}
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
Value(Symbol const* symbol)
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
: Value(SYMBOL_TAG << TAG_SHIFT, reinterpret_cast<void const*>(symbol))
LibJS: Add symbol objects This commit adds the following classes: SymbolObject, SymbolConstructor, SymbolPrototype, and Symbol. This commit does not introduce any new functionality to the Object class, so they cannot be used as property keys in objects.
2020-04-29 23:25:21 -07:00
{
}
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
Value(Accessor const* accessor)
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
: Value(ACCESSOR_TAG << TAG_SHIFT, reinterpret_cast<void const*>(accessor))
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
{
}
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
Value(BigInt const* bigint)
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
: Value(BIGINT_TAG << TAG_SHIFT, reinterpret_cast<void const*>(bigint))
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
{
}
double as_double() const
{
LibJS: Split Value::Type::Number into Int32 and Double We now store 32-bit integers as 32-bit integers directly which avoids having to convert them from doubles when they're only used as 32-bit integers anyway. :^) This patch feels a bit incomplete and there's a lot of opportunities to take advantage of this information. We'll have to find and exploit them eventually.
2021-03-21 18:03:00 +01:00
VERIFY(is_number());
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
if (is_int32())
return static_cast<i32>(m_value.encoded);
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
return m_value.as_double;
}
bool as_bool() const
{
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
VERIFY(is_boolean());
return static_cast<bool>(m_value.encoded & 0x1);
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
}
LibJS: Make Value::as_object() return Object& Let's move towards using references over pointers in LibJS as well. I had originally steered away from it because that's how I've seen things done in other engines. But this is not the other engines. :^)
2020-04-01 22:18:47 +02:00
Object& as_object()
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
{
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
VERIFY(is_object());
return *extract_pointer<Object>();
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
}
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
Object const& as_object() const
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
{
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
VERIFY(is_object());
return *extract_pointer<Object>();
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
}
LibJS: Make Value::as_string() return a PrimitiveString reference
2020-04-29 12:35:39 +02:00
PrimitiveString& as_string()
LibJS: Support "hello friends".length The above snippet is a MemberExpression that necessitates the implicit construction of a StringObject wrapper around a PrimitiveString. We then do a property lookup (a "get") on the StringObject, where we find the "length" property. This is pretty neat! :^)
2020-03-11 18:58:19 +01:00
{
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(is_string());
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 *extract_pointer<PrimitiveString>();
LibJS: Support "hello friends".length The above snippet is a MemberExpression that necessitates the implicit construction of a StringObject wrapper around a PrimitiveString. We then do a property lookup (a "get") on the StringObject, where we find the "length" property. This is pretty neat! :^)
2020-03-11 18:58:19 +01:00
}
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
PrimitiveString const& as_string() const
LibJS: Flesh out JS::Value a little bit more
2020-03-07 23:16:14 +01:00
{
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(is_string());
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 *extract_pointer<PrimitiveString>();
LibJS: Flesh out JS::Value a little bit more
2020-03-07 23:16:14 +01:00
}
LibJS: Add symbol objects This commit adds the following classes: SymbolObject, SymbolConstructor, SymbolPrototype, and Symbol. This commit does not introduce any new functionality to the Object class, so they cannot be used as property keys in objects.
2020-04-29 23:25:21 -07:00
Symbol& as_symbol()
{
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(is_symbol());
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 *extract_pointer<Symbol>();
LibJS: Add symbol objects This commit adds the following classes: SymbolObject, SymbolConstructor, SymbolPrototype, and Symbol. This commit does not introduce any new functionality to the Object class, so they cannot be used as property keys in objects.
2020-04-29 23:25:21 -07:00
}
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
Symbol const& as_symbol() const
LibJS: Add symbol objects This commit adds the following classes: SymbolObject, SymbolConstructor, SymbolPrototype, and Symbol. This commit does not introduce any new functionality to the Object class, so they cannot be used as property keys in objects.
2020-04-29 23:25:21 -07:00
{
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(is_symbol());
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 *extract_pointer<Symbol>();
LibJS: Add symbol objects This commit adds the following classes: SymbolObject, SymbolConstructor, SymbolPrototype, and Symbol. This commit does not introduce any new functionality to the Object class, so they cannot be used as property keys in objects.
2020-04-29 23:25:21 -07:00
}
LibJS: Make Value::as_cell() return a Cell&
2021-05-25 18:48:11 +02:00
Cell& as_cell()
LibJS: Support "hello friends".length The above snippet is a MemberExpression that necessitates the implicit construction of a StringObject wrapper around a PrimitiveString. We then do a property lookup (a "get") on the StringObject, where we find the "length" property. This is pretty neat! :^)
2020-03-11 18:58:19 +01:00
{
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(is_cell());
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 *extract_pointer<Cell>();
LibJS: Support "hello friends".length The above snippet is a MemberExpression that necessitates the implicit construction of a StringObject wrapper around a PrimitiveString. We then do a property lookup (a "get") on the StringObject, where we find the "length" property. This is pretty neat! :^)
2020-03-11 18:58:19 +01:00
}
LibJS: Move Value::as_accessor() to Value.h
2020-06-04 22:00:17 +01:00
Accessor& as_accessor()
{
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(is_accessor());
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 *extract_pointer<Accessor>();
}
BigInt const& as_bigint() const
{
VERIFY(is_bigint());
return *extract_pointer<BigInt>();
LibJS: Move Value::as_accessor() to Value.h
2020-06-04 22:00:17 +01:00
}
LibJS: Add side-effect-free version of Value::to_string() There are now two API's on Value: - Value::to_string(Interpreter&) -- may throw. - Value::to_string_without_side_effects() -- will never throw. These are some pretty big sweeping changes, so it's possible that I did some part the wrong way. We'll work it out as we go. :^) Fixes #2123.
2020-05-15 13:39:24 +02:00
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
BigInt& as_bigint()
{
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(is_bigint());
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 *extract_pointer<BigInt>();
LibJS: Add BigInt
2020-06-06 01:14:10 +01:00
}
LibJS: Add JSON.stringify
2020-06-10 11:01:00 -07:00
Array& as_array();
LibJS: Rename Function => FunctionObject
2021-06-27 21:48:34 +02:00
FunctionObject& as_function();
LibJS: Add const Value::as_function()
2021-09-25 09:43:34 +02:00
FunctionObject const& as_function() const;
LibJS: Add Value::{is, as}_function()
2020-05-06 11:52:53 +01:00
LibJS: Add the Set built-in object
2021-06-09 00:08:47 +03:00
u64 encoded() const { return m_value.encoded; }
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
ThrowCompletionOr<String> to_string(VM&) const;
ThrowCompletionOr<Utf16String> to_utf16_string(VM&) const;
ThrowCompletionOr<PrimitiveString*> to_primitive_string(VM&);
ThrowCompletionOr<Value> to_primitive(VM&, PreferredType preferred_type = PreferredType::Default) const;
ThrowCompletionOr<Object*> to_object(VM&) const;
ThrowCompletionOr<Value> to_numeric(VM&) const;
ThrowCompletionOr<Value> to_number(VM&) const;
ThrowCompletionOr<BigInt*> to_bigint(VM&) const;
ThrowCompletionOr<i64> to_bigint_int64(VM&) const;
ThrowCompletionOr<u64> to_bigint_uint64(VM&) const;
ThrowCompletionOr<double> to_double(VM&) const;
ThrowCompletionOr<PropertyKey> to_property_key(VM&) const;
ThrowCompletionOr<i32> to_i32(VM&) const;
ThrowCompletionOr<u32> to_u32(VM&) const;
ThrowCompletionOr<i16> to_i16(VM&) const;
ThrowCompletionOr<u16> to_u16(VM&) const;
ThrowCompletionOr<i8> to_i8(VM&) const;
ThrowCompletionOr<u8> to_u8(VM&) const;
ThrowCompletionOr<u8> to_u8_clamp(VM&) const;
ThrowCompletionOr<size_t> to_length(VM&) const;
ThrowCompletionOr<size_t> to_index(VM&) const;
ThrowCompletionOr<double> to_integer_or_infinity(VM&) const;
LibJS: Pass Interpreter& to Value::to_number() et al. This patch is unfortunately rather large and might make some things feel bloated, but it is necessary to fix a few flaws in LibJS, primarily blindly coercing values to numbers without exception checks - i.e. interpreter.argument(0).to_i32(); // can fail!!! Some examples where the interpreter would actually crash: var o = { toString: () => { throw Error() } }; +o; o - 1; "foo".charAt(o); "bar".repeat(o); To fix this, we now have the following... to_double(Interpreter&) to_i32() to_i32(Interpreter&) to_size_t() to_size_t(Interpreter&) ...and a whole lot of exception checking. There's intentionally no to_double(), use as_double() directly instead. This way we still can use these convenient utility functions but don't need to check for exceptions if we are sure the value already is a number. Fixes #2267.
2020-05-18 00:28:00 +01:00
bool to_boolean() const;
LibJS: Support "hello friends".length The above snippet is a MemberExpression that necessitates the implicit construction of a StringObject wrapper around a PrimitiveString. We then do a property lookup (a "get") on the StringObject, where we find the "length" property. This is pretty neat! :^)
2020-03-11 18:58:19 +01:00
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
ThrowCompletionOr<Value> get(VM&, PropertyKey const&) const;
ThrowCompletionOr<FunctionObject*> get_method(VM&, PropertyKey const&) const;
LibJS: Implement the GetV() abstract operation Like Get(), but with any value instead of an object - it's calling ToObject() for us and passes the value to [[Get]]() as the receiver. This will be used in GetMethod() (and a couple of other places, which can be updated over time). I also tried something new here: adding the three steps from the spec as inline comments :^)
2021-06-26 19:17:28 +01:00
LibJS: Move Value::as_accessor() to Value.h
2020-06-04 22:00:17 +01:00
String to_string_without_side_effects() const;
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
Optional<BigInt*> string_to_bigint(VM&) const;
LibJS: Move Value::as_accessor() to Value.h
2020-06-04 22:00:17 +01:00
LibJS: Stop using Optional<Value> in favor of Value's empty state JS::Value already has the empty state ({} or Value() gives you one.) Use this instead of wrapping Value in Optional in some places. I've also added Value::value_or(Value) so you can easily provide a fallback value when one is not present.
2020-04-25 18:43:34 +02:00
Value value_or(Value fallback) const
{
if (is_empty())
return fallback;
return *this;
}
LibJS: Move 'typeof' string functionality from AST to Value We should be able to get the 'typeof' string for any value directly, so this is now a standalone Value::typeof() method instead of being part of UnaryExpression::execute().
2021-04-02 20:33:03 +02:00
String typeof() const;
LibJS: Add Value::operator==() This is needed for MarkedValueList::contains_slow() to work.
2021-07-04 17:49:54 +01:00
bool operator==(Value const&) const;
LibJS: Move Object::invoke to Value::invoke and fix it for primitives This is a tiny difference and only changes anything for primitives in strict mode. However this is tested in test262 and can be noticed by overriding toString of primitive values. This does now require one to wrap an object in a Value to call invoke but all code using invoke has been migrated.
2021-08-09 16:45:43 +02:00
template<typename... Args>
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
[[nodiscard]] ALWAYS_INLINE ThrowCompletionOr<Value> invoke(VM&, PropertyKey const& property_key, Args... args);
LibJS: Move Object::invoke to Value::invoke and fix it for primitives This is a tiny difference and only changes anything for primitives in strict mode. However this is tested in test262 and can be noticed by overriding toString of primitive values. This does now require one to wrap an object in a Value to call invoke but all code using invoke has been migrated.
2021-08-09 16:45:43 +02:00
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
private:
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
Value(u64 tag, u64 val)
{
VERIFY((tag & ~TAG_EXTRACTION) == 0);
VERIFY(!(tag & val));
m_value.encoded = tag | val;
}
template<typename PointerType>
Value(u64 tag, PointerType const* ptr)
{
VERIFY((tag & ~TAG_EXTRACTION) == 0);
VERIFY((tag & TAG_EXTRACTION) != 0);
// Cell tag bit must be set or this is a nullptr
VERIFY((tag & 0x8000000000000000ul) == 0x8000000000000000ul || !ptr);
if constexpr (sizeof(PointerType*) < sizeof(u64)) {
m_value.encoded = tag | reinterpret_cast<u32>(ptr);
} else {
VERIFY(!(reinterpret_cast<u64>(ptr) & TAG_EXTRACTION));
m_value.encoded = tag | reinterpret_cast<u64>(ptr);
}
}
// A double is any Value which does not have the full exponent and top mantissa bit set or has
// exactly only those bits set.
bool is_double() const { return (m_value.encoded & CANON_NAN_BITS) != CANON_NAN_BITS || (m_value.encoded == CANON_NAN_BITS); }
bool is_int32() const { return m_value.tag == INT32_TAG; }
i32 as_i32() const
{
VERIFY(is_int32());
return static_cast<i32>(m_value.encoded & 0xFFFFFFFF);
}
template<typename PointerType>
PointerType* extract_pointer() const
{
VERIFY(is_cell());
// For 32-bit system the pointer fully fits so we can just return it directly.
if constexpr (sizeof(PointerType*) < sizeof(u64))
return reinterpret_cast<PointerType*>(static_cast<u32>(m_value.encoded & 0xffffffff));
// For x86_64 the top 16 bits should be sign extending the "real" top bit (47th).
// So first shift the top 16 bits away then using the right shift it sign extends the top 16 bits.
u64 ptr_val = (u64)(((i64)(m_value.encoded << 16)) >> 16);
return reinterpret_cast<PointerType*>(ptr_val);
}
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
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
[[nodiscard]] ThrowCompletionOr<Value> invoke_internal(VM&, PropertyKey const&, Optional<MarkedVector<Value>> arguments);
LibJS: Move Object::invoke to Value::invoke and fix it for primitives This is a tiny difference and only changes anything for primitives in strict mode. However this is tested in test262 and can be noticed by overriding toString of primitive values. This does now require one to wrap an object in a Value to call invoke but all code using invoke has been migrated.
2021-08-09 16:45:43 +02:00
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
ThrowCompletionOr<i32> to_i32_slow_case(VM&) const;
LibJS: Split Value::Type::Number into Int32 and Double We now store 32-bit integers as 32-bit integers directly which avoids having to convert them from doubles when they're only used as 32-bit integers anyway. :^) This patch feels a bit incomplete and there's a lot of opportunities to take advantage of this information. We'll have to find and exploit them eventually.
2021-03-21 18:03:00 +01:00
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
union {
double as_double;
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
struct {
u64 payload : 48;
u64 tag : 16;
};
LibJS: Add the Set built-in object
2021-06-09 00:08:47 +03:00
u64 encoded;
} m_value { .encoded = 0 };
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
friend Value js_undefined();
friend Value js_null();
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
friend ThrowCompletionOr<Value> greater_than(VM&, Value lhs, Value rhs);
friend ThrowCompletionOr<Value> greater_than_equals(VM&, Value lhs, Value rhs);
friend ThrowCompletionOr<Value> less_than(VM&, Value lhs, Value rhs);
friend ThrowCompletionOr<Value> less_than_equals(VM&, Value lhs, Value rhs);
friend ThrowCompletionOr<Value> add(VM&, Value lhs, Value rhs);
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
friend bool same_value_non_numeric(Value lhs, Value rhs);
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
};
inline Value js_undefined()
{
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 Value(UNDEFINED_TAG << TAG_SHIFT, (u64)0);
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
}
inline Value js_null()
{
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 Value(NULL_TAG << TAG_SHIFT, (u64)0);
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
}
LibJS: Basic NaN support This patch adds js_nan() for constructing a NaN value. You can check if a Value is NaN with Value::is_nan().
2020-03-27 12:26:37 +01:00
inline Value js_nan()
{
LibM: Add NAN macro
2020-06-04 13:03:15 +01:00
return Value(NAN);
LibJS: Basic NaN support This patch adds js_nan() for constructing a NaN value. You can check if a Value is NaN with Value::is_nan().
2020-03-27 12:26:37 +01:00
}
LibJS: Implement Infinity
2020-04-02 16:59:01 +01:00
inline Value js_infinity()
{
LibM: Add INFINITY macro
2020-06-04 13:05:27 +01:00
return Value(INFINITY);
LibJS: Implement Infinity
2020-04-02 16:59:01 +01:00
}
LibJS: Add js_negative_infinity() Value(-js_infinity().as_double()) is kind of awkward.
2020-04-12 13:25:42 +01:00
inline Value js_negative_infinity()
{
LibM: Add INFINITY macro
2020-06-04 13:05:27 +01:00
return Value(-INFINITY);
LibJS: Add js_negative_infinity() Value(-js_infinity().as_double()) is kind of awkward.
2020-04-12 13:25:42 +01:00
}
LibJS: Inline Cell::Visitor::visit() functions This allows the calls to MarkingVisitor::visit_impl() during GC to be devirtualized in Heap::mark_live_cells().
2021-05-25 18:17:41 +02:00
inline void Cell::Visitor::visit(Value value)
{
if (value.is_cell())
LibJS: Make Value::as_cell() return a Cell&
2021-05-25 18:48:11 +02:00
visit_impl(value.as_cell());
LibJS: Inline Cell::Visitor::visit() functions This allows the calls to MarkingVisitor::visit_impl() during GC to be devirtualized in Heap::mark_live_cells().
2021-05-25 18:17:41 +02:00
}
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
ThrowCompletionOr<Value> greater_than(VM&, Value lhs, Value rhs);
ThrowCompletionOr<Value> greater_than_equals(VM&, Value lhs, Value rhs);
ThrowCompletionOr<Value> less_than(VM&, Value lhs, Value rhs);
ThrowCompletionOr<Value> less_than_equals(VM&, Value lhs, Value rhs);
ThrowCompletionOr<Value> bitwise_and(VM&, Value lhs, Value rhs);
ThrowCompletionOr<Value> bitwise_or(VM&, Value lhs, Value rhs);
ThrowCompletionOr<Value> bitwise_xor(VM&, Value lhs, Value rhs);
ThrowCompletionOr<Value> bitwise_not(VM&, Value);
ThrowCompletionOr<Value> unary_plus(VM&, Value);
ThrowCompletionOr<Value> unary_minus(VM&, Value);
ThrowCompletionOr<Value> left_shift(VM&, Value lhs, Value rhs);
ThrowCompletionOr<Value> right_shift(VM&, Value lhs, Value rhs);
ThrowCompletionOr<Value> unsigned_right_shift(VM&, Value lhs, Value rhs);
ThrowCompletionOr<Value> add(VM&, Value lhs, Value rhs);
ThrowCompletionOr<Value> sub(VM&, Value lhs, Value rhs);
ThrowCompletionOr<Value> mul(VM&, Value lhs, Value rhs);
ThrowCompletionOr<Value> div(VM&, Value lhs, Value rhs);
ThrowCompletionOr<Value> mod(VM&, Value lhs, Value rhs);
ThrowCompletionOr<Value> exp(VM&, Value lhs, Value rhs);
ThrowCompletionOr<Value> in(VM&, Value lhs, Value rhs);
ThrowCompletionOr<Value> instance_of(VM&, Value lhs, Value rhs);
ThrowCompletionOr<Value> ordinary_has_instance(VM&, Value lhs, Value rhs);
ThrowCompletionOr<bool> is_loosely_equal(VM&, Value lhs, Value rhs);
LibJS: Rename strict_eq() to is_strictly_equal() This got turned into a proper AO with a new name recently. See: https://github.com/tc39/ecma262/commit/19d7ca4
2021-09-23 23:43:28 +02:00
bool is_strictly_equal(Value lhs, Value rhs);
LibJS: Make native function/property callbacks take VM, not Interpreter More work on decoupling the general runtime from Interpreter. The goal is becoming clearer. Interpreter should be one possible way to execute code inside a VM. In the future we might have other ways :^)
2020-09-27 18:36:49 +02:00
bool same_value(Value lhs, Value rhs);
bool same_value_zero(Value lhs, Value rhs);
bool same_value_non_numeric(Value lhs, Value rhs);
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
ThrowCompletionOr<TriState> is_less_than(VM&, Value lhs, Value rhs, bool left_first);
LibJS: Spec-compliant equality comparisons The ECMAScript spec defines multiple equality operations which are used all over the spec; this patch introduces them. Of course, the two primary equality operations are AbtractEquals ('==') and StrictEquals ('==='), which have been renamed to 'abstract_eq' and 'strict_eq' in this patch. In support of the two operations mentioned above, the following have also been added: SameValue, SameValueZero, and SameValueNonNumeric. These are important to have, because they are used elsewhere in the spec aside from the two primary equality comparisons.
2020-05-07 17:09:00 -07:00
LibJS: Add variant of to_integer_or_infinity() for plain doubles In many cases we already know a certain value is a number, or don't have JS values at all and would need to wrap doubles in a value. To optimize these cases and avoid having to pass a global object into functions that won't ever allocate or throw, add a standalone implementation of this function that takes and returns doubles directly.
2022-05-06 20:17:16 +02:00
double to_integer_or_infinity(double);
LibJS: Add Value::operator==() This is needed for MarkedValueList::contains_slow() to work.
2021-07-04 17:49:54 +01:00
inline bool Value::operator==(Value const& value) const { return same_value(*this, value); }
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
}
namespace AK {
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
static_assert(sizeof(JS::Value) == sizeof(double));
LibJS: Specialize Optional<Value> Values can be "empty" which only has a valid meaning for array holes. We can however use this state the represent the empty state of an Optional<Value> which is used in a lot of placed, because of Completion having one. This saves 8 bytes for every Optional<Value>.
2022-02-28 21:33:45 +01:00
template<>
class Optional<JS::Value> {
template<typename U>
friend class Optional;
public:
using ValueType = JS::Value;
Optional() = default;
Optional(Optional<JS::Value> const& other)
{
if (other.has_value())
m_value = other.m_value;
}
Optional(Optional&& other)
: m_value(other.m_value)
{
}
template<typename U = JS::Value>
explicit(!IsConvertible<U&&, JS::Value>) Optional(U&& value) requires(!IsSame<RemoveCVReference<U>, Optional<JS::Value>> && IsConstructible<JS::Value, U&&>)
: m_value(forward<U>(value))
{
}
Optional& operator=(Optional const& other)
{
if (this != &other) {
clear();
m_value = other.m_value;
}
return *this;
}
Optional& operator=(Optional&& other)
{
if (this != &other) {
clear();
m_value = other.m_value;
}
return *this;
}
void clear()
{
m_value = {};
}
[[nodiscard]] bool has_value() const
{
return !m_value.is_empty();
}
[[nodiscard]] JS::Value& value() &
{
VERIFY(has_value());
return m_value;
}
[[nodiscard]] JS::Value const& value() const&
{
VERIFY(has_value());
return m_value;
}
[[nodiscard]] JS::Value value() &&
{
return release_value();
}
[[nodiscard]] JS::Value release_value()
{
VERIFY(has_value());
JS::Value released_value = m_value;
clear();
return released_value;
}
JS::Value value_or(JS::Value const& fallback) const&
{
if (has_value())
return value();
return fallback;
}
[[nodiscard]] JS::Value value_or(JS::Value&& fallback) &&
{
if (has_value())
return value();
return fallback;
}
JS::Value const& operator*() const { return value(); }
JS::Value& operator*() { return value(); }
JS::Value const* operator->() const { return &value(); }
JS::Value* operator->() { return &value(); }
private:
JS::Value m_value;
};
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
template<>
struct Formatter<JS::Value> : Formatter<StringView> {
AK: Convert AK::Format formatting helpers to returning ErrorOr<void> This isn't a complete conversion to ErrorOr<void>, but a good chunk. The end goal here is to propagate buffer allocation failures to the caller, and allow the use of TRY() with formatting functions.
2021-11-16 01:15:21 +01:00
ErrorOr<void> format(FormatBuilder& builder, JS::Value value)
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
{
AK: Convert AK::Format formatting helpers to returning ErrorOr<void> This isn't a complete conversion to ErrorOr<void>, but a good chunk. The end goal here is to propagate buffer allocation failures to the caller, and allow the use of TRY() with formatting functions.
2021-11-16 01:15:21 +01:00
return Formatter<StringView>::format(builder, value.is_empty() ? "<empty>" : value.to_string_without_side_effects());
LibJS: Use new format functions everywhere This changes the remaining uses of the following functions across LibJS: - String::format() => String::formatted() - dbg() => dbgln() - printf() => out(), outln() - fprintf() => warnln() I also removed the relevant 'LogStream& operator<<' overloads as they're not needed anymore.
2020-12-06 16:55:19 +00:00
}
};
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
}
Reference in a new issue Copy permalink