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

278 lines
12 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
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02:00
* Copyright (c) 2020-2024, Andreas Kling <andreas@ladybird.org>
LibJS: Fix return type of Object::create_method_property() This doesn't return a completion in the spec as it doesn't need to propagate any errors. It's also unused right now, which is probably why no one noticed.
2023-03-11 17:27:17 +00:00
* Copyright (c) 2020-2023, Linus Groh <linusg@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
LibJS: Avoid pointless transitions and metadata lookups in storage_set() - Replace the misleading abuse of the m_transitions_enabled flag for the fast path without lookup with a new m_initialized boolean that's set either by Heap::allocate() after calling the Object's initialize(), or by the GlobalObject in its special initialize_global_object(). This makes it work regardless of the shape's uniqueness. - When we're adding a new property past the initialization phase, there's no need to do a second metadata lookup to retrieve the storage value offset - it's known to always be the shape's property count minus one. Also, instead of doing manual storage resizing and assignment via indexing, just use Vector::append(). - When we didn't add a new property but are overwriting an existing one, the property count and therefore storage value offset doesn't change, so we don't have to retrieve it either. As a result, Object::set_shape() is now solely responsible for updating the m_shape pointer and is not resizing storage anymore, so I moved it into the header.
2021-08-28 17:12:14 +01:00
#include <AK/Badge.h>
DevTools+LibJS+LibWeb: Change class_name to use StringView This helps make the overall codebase consistent. `class_name()` in `Kernel` is always `StringView`, but not elsewhere. Additionally, this results in the `strlen` (which needs to be done when printing or other operations) always being computed at compile-time.
2022-03-16 18:26:49 -06:00
#include <AK/StringView.h>
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
#include <LibGC/CellAllocator.h>
LibGC: Rename MarkedVector => RootVector Let's try to make it a bit more clear that this is a Vector of GC roots.
2024-12-26 14:32:52 +01:00
#include <LibGC/RootVector.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 Cell.{cpp,h} from Runtime/ to Heap/
2021-05-17 19:50:20 +02:00
#include <LibJS/Heap/Cell.h>
LibJS: Convert internal_get_prototype_of() to ThrowCompletionOr
2021-09-28 23:30:17 +01:00
#include <LibJS/Runtime/Completion.h>
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
#include <LibJS/Runtime/IndexedProperties.h>
LibJS: Add "Heap" and "Runtime" subdirectories Let's try to keep LibJS tidy as it expands. :^)
2020-03-16 14:20:30 +01:00
#include <LibJS/Runtime/PrimitiveString.h>
LibJS: Add slot [[PrivateElements]] and related methods to Object
2021-10-12 21:44:47 +02:00
#include <LibJS/Runtime/PrivateEnvironment.h>
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
#include <LibJS/Runtime/PropertyDescriptor.h>
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
#include <LibJS/Runtime/PropertyKey.h>
LibJS: Implement correct attributes for (almost) all properties Added the ability to include a u8 attributes parameter with all of the various put methods in the Object class. They can be omitted, in which case it defaults to "Writable | Enumerable | Configurable", just like before this commit. All of the attribute values for each property were gathered from SpiderMonkey in the Firefox console. Some properties (e.g. all of the canvas element properties) have undefined property descriptors... not quite sure what that means. Those were left as the default specified above.
2020-04-27 23:05:02 -07:00
#include <LibJS/Runtime/Shape.h>
LibJS: Add "Heap" and "Runtime" subdirectories Let's try to keep LibJS tidy as it expands. :^)
2020-03-16 14:20:30 +01:00
#include <LibJS/Runtime/Value.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
namespace JS {
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
#define JS_OBJECT(class_, base_class) GC_CELL(class_, base_class)
LibJS+LibWeb: Add JS::Object::inherits(class_name) To allow implementing the DOM class hierarchy in JS bindings, this patch adds an inherits() function that can be used to ask an Object if it inherits from a specific C++ class (by name). The necessary overrides are baked into each Object subclass by the new JS_OBJECT macro, which works similarly to C_OBJECT in LibCore. Thanks to @Dexesttp for suggesting this approach. :^)
2020-06-21 15:14:02 +02:00
LibJS: Add slot [[PrivateElements]] and related methods to Object
2021-10-12 21:44:47 +02:00
struct PrivateElement {
enum class Kind {
Field,
Method,
Accessor
};
PrivateName key;
Kind kind { Kind::Field };
LibJS: Don't use Handle<Value> for JS::Object private fields There's no reason to use handles here, we can just mark private element values from objects that store them.
2023-12-09 11:05:25 +01:00
Value value;
LibJS: Add slot [[PrivateElements]] and related methods to Object
2021-10-12 21:44:47 +02:00
};
LibJS: Make Object::internal_get() reveal the used property offset This function now takes an optional out parameter for callers who would like to what kind of property we ended up getting. This will be used to implement inline caching for property lookups. Also, to prepare for adding more forms of caching, the out parameter is a struct CacheablePropertyMetadata rather than just an offset. :^)
2023-07-08 17:39:18 +02:00
// Non-standard: This is information optionally returned by object property access functions.
// It can be used to implement inline caches for property lookup.
struct CacheablePropertyMetadata {
enum class Type {
NotCacheable,
OwnProperty,
LibJS: Cache access to properties found in prototype chain We already had fast access to own properties via shape-based IC. This patch extends the mechanism to properties on the prototype chain, using the "validity cell" technique from V8. - Prototype objects now have unique shape - Each prototype has an associated PrototypeChainValidity - When a prototype shape is mutated, every prototype shape "below" it in any prototype chain is invalidated. - Invalidation happens by marking the validity object as invalid, and then replacing it with a new validity object. - Property caches keep a pointer to the last seen valid validity. If there is no validity, or the validity is invalid, the cache misses and gets repopulated. This is very helpful when using JavaScript to access DOM objects, as we frequently have to traverse 4+ prototype objects before finding the property we're interested in on e.g EventTarget or Node.
2024-05-04 15:48:23 +02:00
InPrototypeChain,
LibJS: Make Object::internal_get() reveal the used property offset This function now takes an optional out parameter for callers who would like to what kind of property we ended up getting. This will be used to implement inline caching for property lookups. Also, to prepare for adding more forms of caching, the out parameter is a struct CacheablePropertyMetadata rather than just an offset. :^)
2023-07-08 17:39:18 +02:00
};
Type type { Type::NotCacheable };
Optional<u32> property_offset;
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<Object const> prototype;
LibJS: Make Object::internal_get() reveal the used property offset This function now takes an optional out parameter for callers who would like to what kind of property we ended up getting. This will be used to implement inline caching for property lookups. Also, to prepare for adding more forms of caching, the out parameter is a struct CacheablePropertyMetadata rather than just an offset. :^)
2023-07-08 17:39:18 +02:00
};
LibJS: Add a basic mark&sweep garbage collector :^) Objects can now be allocated via the interpreter's heap. Objects that are allocated in this way will need to be provably reachable from at least one of the known object graph roots. The roots are currently determined by Heap::collect_roots(). Anything that wants be collectable garbage should inherit from Cell, the fundamental atom of the GC heap. This is pretty neat! :^)
2020-03-08 19:23:58 +01:00
class Object : public Cell {
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC_CELL(Object, Cell);
GC_DECLARE_ALLOCATOR(Object);
LibJS: Add JS_CELL macro and use it in all JS::Cell subclasses This is similar to what we already had with JS_OBJECT (and also JS_ENVIRONMENT) but sits at the top of the Cell inheritance hierarchy.
2022-08-28 22:11:20 +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
public:
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
static GC::Ref<Object> create_prototype(Realm&, Object* prototype);
static GC::Ref<Object> create(Realm&, Object* prototype);
static GC::Ref<Object> create_with_premade_shape(Shape&);
LibJS+LibWeb: Pass prototype to Object constructor Everyone who constructs an Object must now pass a prototype object when applicable. There's still a fair amount of code that passes something fetched from the Interpreter, but this brings us closer to being able to detach prototypes from Interpreter eventually.
2020-04-18 10:27:57 +02:00
LibJS: Make Cell::initialize() return void Stop worrying about tiny OOMs. Work towards #20405
2023-08-07 08:41:28 +02:00
virtual void initialize(Realm&) override;
LibJS: Support instrinsic Object properties with deferred evaluation For performance, it is desirable to defer evaluation of intrinsics that are stored on the GlobalObject for every created Realm. To support this, Object now maintains a global storage map to store lambdas that will return the associated intrinsic when evaluated. Once accessed, the instrinsic is moved from this global map to normal Object storage. To prevent this flow from becoming observable, when a deferred intrinsic is stored, we still place an empty object in the normal Object storage. This is so we still create the metadata for the object, and in doing so, can preserve insertion order of the Object storage. Otherwise, this will be observable by way of Object.getOwnPropertyDescriptors.
2022-11-24 09:41:24 -05:00
virtual ~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: Renamed Object::GetOwnPropertyReturnMode to Object::PropertyKind This enum will be used by iterators, so it makes sense to use a more general name.
2020-07-09 14:42:30 -07:00
enum class PropertyKind {
LibJS: Implement most of the Reflect object
2020-05-01 11:06:27 +01:00
Key,
Value,
KeyAndValue,
};
LibJS: Implement Object.freeze() and Object.seal()
2021-04-06 22:06:11 +02:00
enum class IntegrityLevel {
Sealed,
Frozen,
};
LibJS: Replace the boolean argument of Object::set with an enum class This is more serenity-esque and also makes pointing out missing exception checks during reviews much easier.
2021-07-16 15:16:27 +03:00
enum class ShouldThrowExceptions {
No,
Yes,
};
LibJS+LibWeb: Devirtualize may_interfere_with_indexed_property_access()
2023-11-09 07:29:52 +00:00
enum class MayInterfereWithIndexedPropertyAccess {
No,
Yes,
};
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
// Please DO NOT make up your own non-standard methods unless you
// have a very good reason to do so. If any object abstract
// operation from the spec is missing, add it instead.
// Functionality for implementation details like shapes and
// property storage are obviously exempt from this rule :^)
//
// Methods named [[Foo]]() in the spec are named internal_foo()
// here, as they are "The [[Foo]] internal method of a ... object".
// They must be virtual and may be overridden. All other methods
LibJS: Fix a typo in a comment in Object.h
2021-09-29 19:20:28 +01:00
// follow the regular PascalCase name converted to camel_case
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
// naming convention and must not be virtual.
// 7.1 Type Conversion, https://tc39.es/ecma262/#sec-type-conversion
LibJS: Convert ordinary_to_primitive() to ThrowCompletionOr Also add spec step comments to it while we're here.
2021-10-02 15:13:09 +01:00
ThrowCompletionOr<Value> ordinary_to_primitive(Value::PreferredType preferred_type) const;
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
// 7.2 Testing and Comparison Operations, https://tc39.es/ecma262/#sec-testing-and-comparison-operations
LibJS: Convert is_extensible() to ThrowCompletionOr
2021-10-02 15:27:37 +01:00
ThrowCompletionOr<bool> is_extensible() const;
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
// 7.3 Operations on Objects, https://tc39.es/ecma262/#sec-operations-on-objects
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
ThrowCompletionOr<Value> get(PropertyKey const&) const;
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
ThrowCompletionOr<void> set(PropertyKey const&, Value, ShouldThrowExceptions);
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
ThrowCompletionOr<bool> create_data_property(PropertyKey const&, Value);
LibJS: Fix return type of Object::create_method_property() This doesn't return a completion in the spec as it doesn't need to propagate any errors. It's also unused right now, which is probably why no one noticed.
2023-03-11 17:27:17 +00:00
void create_method_property(PropertyKey const&, Value);
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
ThrowCompletionOr<bool> create_data_property_or_throw(PropertyKey const&, Value);
LibJS: Remove implicit wrapping/unwrapping of completion records This is an editorial change in the ECMA-262 spec, with similar changes in some proposals. See: - https://github.com/tc39/ecma262/commit/7575f74 - https://github.com/tc39/proposal-array-grouping/commit/df899eb - https://github.com/tc39/proposal-shadowrealm/commit/9eb5a12 - https://github.com/tc39/proposal-shadowrealm/commit/c81f527
2022-05-02 20:54:39 +02:00
void create_non_enumerable_data_property_or_throw(PropertyKey const&, Value);
ThrowCompletionOr<void> define_property_or_throw(PropertyKey const&, PropertyDescriptor const&);
ThrowCompletionOr<void> delete_property_or_throw(PropertyKey const&);
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
ThrowCompletionOr<bool> has_property(PropertyKey const&) const;
ThrowCompletionOr<bool> has_own_property(PropertyKey const&) const;
LibJS: Convert set_integrity_level() to ThrowCompletionOr
2021-10-03 02:20:19 +01:00
ThrowCompletionOr<bool> set_integrity_level(IntegrityLevel);
LibJS: Convert test_integrity_level() to ThrowCompletionOr
2021-10-03 02:21:44 +01:00
ThrowCompletionOr<bool> test_integrity_level(IntegrityLevel) const;
LibGC: Rename MarkedVector => RootVector Let's try to make it a bit more clear that this is a Vector of GC roots.
2024-12-26 14:32:52 +01:00
ThrowCompletionOr<GC::RootVector<Value>> enumerable_own_property_names(PropertyKind kind) const;
LibJS: Implement excluded values in CopyDataProperties This is a change to this AO as part of the Temporal proposal.
2024-01-04 19:52:46 +13:00
ThrowCompletionOr<void> copy_data_properties(VM&, Value source, HashTable<PropertyKey> const& excluded_keys, HashTable<JS::Value> const& excluded_values = {});
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
ThrowCompletionOr<GC::Ref<Object>> snapshot_own_properties(VM&, GC::Ptr<Object> prototype, HashTable<PropertyKey> const& excluded_keys = {}, HashTable<Value> const& excluded_values = {});
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
LibJS: Add slot [[PrivateElements]] and related methods to Object
2021-10-12 21:44:47 +02:00
PrivateElement* private_element_find(PrivateName const& name);
ThrowCompletionOr<void> private_field_add(PrivateName const& name, Value value);
ThrowCompletionOr<void> private_method_or_accessor_add(PrivateElement element);
ThrowCompletionOr<Value> private_get(PrivateName const& name);
ThrowCompletionOr<void> private_set(PrivateName const& name, Value value);
LibJS: De-duplicate ClassFieldDefinition Records This was defined twice, despite being the very same thing: - ClassElement::ClassFieldDefinition - ECMAScriptFunctionObject::InstanceField Move the former to a new header and use it everywhere. Also update the define_field() AO to take a single field instead of separate name and initializer arguments.
2022-04-20 00:06:45 +02:00
ThrowCompletionOr<void> define_field(ClassFieldDefinition const&);
LibJS: Move initialize_instance_elements() from VM to Object This makes more sense as an Object method rather than living within the VM class for no good reason. Most of the other 7.3.xx AOs already work the same way. Also add spec comments while we're here.
2022-12-07 00:22:23 +00:00
ThrowCompletionOr<void> initialize_instance_elements(ECMAScriptFunctionObject& constructor);
LibJS: Add slot [[PrivateElements]] and related methods to Object
2021-10-12 21:44:47 +02:00
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
// 10.1 Ordinary Object Internal Methods and Internal Slots, https://tc39.es/ecma262/#sec-ordinary-object-internal-methods-and-internal-slots
LibJS: Always keep a reference to the global object in Shape We need to move towards supporting multiple global objects, which will be a large refactoring. To keep it manageable, let's do it in steps, starting with giving Object a way to find the GlobalObject it lives inside by asking its Shape for it.
2020-06-08 12:15:58 +02:00
LibJS: Convert internal_get_prototype_of() to ThrowCompletionOr
2021-09-28 23:30:17 +01:00
virtual ThrowCompletionOr<Object*> internal_get_prototype_of() const;
LibJS: Convert internal_set_prototype_of() to ThrowCompletionOr
2021-09-28 23:54:42 +01:00
virtual ThrowCompletionOr<bool> internal_set_prototype_of(Object* prototype);
LibJS: Convert internal_is_extensible() to ThrowCompletionOr
2021-09-29 00:02:05 +01:00
virtual ThrowCompletionOr<bool> internal_is_extensible() const;
LibJS: Convert internal_prevent_extensions() to ThrowCompletionOr
2021-09-29 00:13:41 +01:00
virtual ThrowCompletionOr<bool> internal_prevent_extensions();
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
virtual ThrowCompletionOr<Optional<PropertyDescriptor>> internal_get_own_property(PropertyKey const&) const;
LibJS+LibWeb: Prevent double invocation of `[[GetOwnProperty]]` The `[[GetOwnProperty]]` internal method invocation in `OrdinarySetWithOwnDescriptor` was being invocated again with the same parameters in the `[[DefineOwnProperty]]` internal method that is also later called in `OrdinarySetWithOwnDescriptor`. The `PlatformObject.[[DefineOwnProperty]]` has similair logic. This change adds an optional parameter to the `[[DefineOwnProperty]]` internal method so the results of the previous `[[GetOwnProperty]]` internal method invocation can be re-used.
2024-11-01 21:03:18 +01:00
virtual ThrowCompletionOr<bool> internal_define_own_property(PropertyKey const&, PropertyDescriptor const&, Optional<PropertyDescriptor>* precomputed_get_own_property = nullptr);
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
virtual ThrowCompletionOr<bool> internal_has_property(PropertyKey const&) const;
LibJS: Add PropertyLookupPhase enum to distinguish Object [[Get]] calls We can now tell the difference between an own property access and a subsequent (automatic) prototype chain access. This will be used to implement caching of prototype chain accesses.
2024-05-02 11:13:08 +02:00
enum class PropertyLookupPhase {
OwnProperty,
PrototypeChain,
};
virtual ThrowCompletionOr<Value> internal_get(PropertyKey const&, Value receiver, CacheablePropertyMetadata* = nullptr, PropertyLookupPhase = PropertyLookupPhase::OwnProperty) const;
LibJS: Add basic monomorphic caching for PutById property access This patch makes it possible for JS::Object::internal_set() to populate a CacheablePropertyMetadata, and uses this to implement a basic monomorphic cache for the most common form of property write access.
2023-11-08 20:51:26 +01:00
virtual ThrowCompletionOr<bool> internal_set(PropertyKey const&, Value value, Value receiver, CacheablePropertyMetadata* = nullptr);
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
virtual ThrowCompletionOr<bool> internal_delete(PropertyKey const&);
LibGC: Rename MarkedVector => RootVector Let's try to make it a bit more clear that this is a Vector of GC roots.
2024-12-26 14:32:52 +01:00
virtual ThrowCompletionOr<GC::RootVector<Value>> internal_own_property_keys() const;
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
LibJS: Add Object::may_interfere_with_indexed_property_access() virtual This function must return true if the object may intercept and customize access to indexed properties (properties where the property name is a non-negative integer.) This will be used to implement fast path optimizations for array-like accesses in subsequent commits.
2023-10-05 08:58:30 +02:00
// NOTE: Any subclass of Object that overrides property access slots ([[Get]], [[Set]] etc)
// to customize access to indexed properties (properties where the name is a positive integer)
// must return true for this, to opt out of optimizations that rely on assumptions that
// might not hold when property access behaves differently.
LibJS+LibWeb: Devirtualize may_interfere_with_indexed_property_access()
2023-11-09 07:29:52 +00:00
bool may_interfere_with_indexed_property_access() const { return m_may_interfere_with_indexed_property_access; }
LibJS: Add Object::may_interfere_with_indexed_property_access() virtual This function must return true if the object may intercept and customize access to indexed properties (properties where the property name is a non-negative integer.) This will be used to implement fast path optimizations for array-like accesses in subsequent commits.
2023-10-05 08:58:30 +02:00
LibJS: Add basic monomorphic caching for PutById property access This patch makes it possible for JS::Object::internal_set() to populate a CacheablePropertyMetadata, and uses this to implement a basic monomorphic cache for the most common form of property write access.
2023-11-08 20:51:26 +01:00
ThrowCompletionOr<bool> ordinary_set_with_own_descriptor(PropertyKey const&, Value, Value, Optional<PropertyDescriptor>, CacheablePropertyMetadata* = nullptr);
LibJS: Make Object::ordinary_set_with_own_descriptor non-static This needs to be accessible for implementing IDL legacy platform objects.
2021-09-24 19:39:01 +01:00
LibJS: Make ObjectPrototype an immutable prototype exotic object To make this happen, this patch implements the SetImmutablePrototype abstract operation (as a method on Object) and then overrides [[SetPrototypeOf]] on ObjectPrototype.
2021-07-04 23:48:47 +01:00
// 10.4.7 Immutable Prototype Exotic Objects, https://tc39.es/ecma262/#sec-immutable-prototype-exotic-objects
LibJS: Convert set_immutable_prototype() to ThrowCompletionOr
2021-10-03 19:52:13 +01:00
ThrowCompletionOr<bool> set_immutable_prototype(Object* prototype);
LibJS: Make ObjectPrototype an immutable prototype exotic object To make this happen, this patch implements the SetImmutablePrototype abstract operation (as a method on Object) and then overrides [[SetPrototypeOf]] on ObjectPrototype.
2021-07-04 23:48:47 +01:00
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
// 20.1 Object Objects, https://tc39.es/ecma262/#sec-object-objects
LibJS: Convert define_properties() to ThrowCompletionOr
2021-10-03 19:54:37 +01:00
ThrowCompletionOr<Object*> define_properties(Value properties);
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
LibJS: Implement the EnumerateObjectProperties AO
2022-03-29 00:18:15 +03:00
// 14.7.5 The for-in, for-of, and for-await-of Statements
AK+Userland: Remove NOESCAPE See the next commit for an explanation
2024-05-17 17:09:20 -07:00
Optional<Completion> enumerate_object_properties(Function<Optional<Completion>(Value)>) const;
LibJS: Implement the EnumerateObjectProperties AO
2022-03-29 00:18:15 +03:00
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
// Implementation-specific storage abstractions
LibJS: Add a number-indexed property storage to all Objects Objects can have both named and indexed properties. Previously we kept all property names as strings. This patch separates named and indexed properties and splits them between Object::m_storage and m_elements. This allows us to do much faster array-style access using numeric indices. It also makes the Array class much less special, since all Objects now have number-indexed storage. :^)
2020-04-06 16:53:02 +02:00
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
Optional<ValueAndAttributes> storage_get(PropertyKey const&) const;
bool storage_has(PropertyKey const&) const;
void storage_set(PropertyKey const&, ValueAndAttributes const&);
void storage_delete(PropertyKey const&);
LibJS: Virtualize access to an Object's own properties Object now has virtual get_own_property() and put_own_property() member functions that can be overridden to provide custom behavior. We use these virtuals to move Array-specific access behavior to Array.
2020-03-21 14:37:34 +01:00
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
// Non-standard methods
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
Value get_without_side_effects(PropertyKey const&) const;
LibJS: Add Object.defineProperty() and start caring about attributes We now care (a little bit) about the "configurable" and "writable" property attributes. Property attributes are stored together with the property name in the Shape object. Forward transitions are not attribute-savvy and will cause poor Shape reuse in the case of multiple same-name properties with different attributes. Oh, and this patch also adds Object.getOwnPropertyDescriptor() :^)
2020-04-09 22:15:26 +02:00
Everywhere: Remove needless trailing semi-colons after functions This is a new option in clang-format-16.
2023-07-07 22:48:11 -04:00
void define_direct_property(PropertyKey const& property_key, Value value, PropertyAttributes attributes) { storage_set(property_key, { value, attributes }); }
LibJS: Rename PropertyName to PropertyKey Let's use the same name as the spec. :^)
2021-10-24 16:01:24 +02:00
void define_direct_accessor(PropertyKey const&, FunctionObject* getter, FunctionObject* setter, PropertyAttributes attributes);
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: Support instrinsic Object properties with deferred evaluation For performance, it is desirable to defer evaluation of intrinsics that are stored on the GlobalObject for every created Realm. To support this, Object now maintains a global storage map to store lambdas that will return the associated intrinsic when evaluated. Once accessed, the instrinsic is moved from this global map to normal Object storage. To prevent this flow from becoming observable, when a deferred intrinsic is stored, we still place an empty object in the normal Object storage. This is so we still create the metadata for the object, and in doing so, can preserve insertion order of the Object storage. Otherwise, this will be observable by way of Object.getOwnPropertyDescriptors.
2022-11-24 09:41:24 -05:00
using IntrinsicAccessor = Value (*)(Realm&);
LibJS: Mark classes and virtual functions `final` where possible These cases were found with GCC's `-Wsuggest-final-{types,methods}` warnings, which catch calls that could have been devirtualized had we declared the functions `final` in the source. To reproduce, Link Time Optimization needs to be enabled. The easiest way to achieve this is to set the `CMAKE_INTERPROCEDURAL_OPTIMIZATION` cache variable to `ON`. The `.incbin` directive in LibCompress' Brotli decompressor might needs to be changed to an absolute path for this to work. This commit also removes a pair of unused virtual functions.
2023-08-13 12:53:46 +02:00
void define_intrinsic_accessor(PropertyKey const&, PropertyAttributes attributes, IntrinsicAccessor accessor);
LibJS: Support instrinsic Object properties with deferred evaluation For performance, it is desirable to defer evaluation of intrinsics that are stored on the GlobalObject for every created Realm. To support this, Object now maintains a global storage map to store lambdas that will return the associated intrinsic when evaluated. Once accessed, the instrinsic is moved from this global map to normal Object storage. To prevent this flow from becoming observable, when a deferred intrinsic is stored, we still place an empty object in the normal Object storage. This is so we still create the metadata for the object, and in doing so, can preserve insertion order of the Object storage. Otherwise, this will be observable by way of Object.getOwnPropertyDescriptors.
2022-11-24 09:41:24 -05:00
Userland: Add ESCAPING annotations to a bunch of places This isn't comprehensive; just a result of a simple grep search.
2024-05-17 17:14:06 -07:00
void define_native_function(Realm&, PropertyKey const&, ESCAPING Function<ThrowCompletionOr<Value>(VM&)>, i32 length, PropertyAttributes attributes, Optional<Bytecode::Builtin> builtin = {});
void define_native_accessor(Realm&, PropertyKey const&, ESCAPING Function<ThrowCompletionOr<Value>(VM&)> getter, ESCAPING Function<ThrowCompletionOr<Value>(VM&)> setter, PropertyAttributes attributes);
LibJS: Convert NativeFunction callback to ThrowCompletionOr
2021-10-19 22:53:27 +03:00
LibJS+LibWeb: Add fast_is<DOM::Node> for JS::Object Solves problem that is<DOM::Node, JS::Object>() is quite hot in profiles while loading https://www.postgresql.org/about/featurematrix/.
2023-07-13 19:54:03 +02:00
virtual bool is_dom_node() const { return false; }
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
virtual bool is_function() const { return false; }
LibJS: Add fast_is<T> helpers for all the primitive wrapper objects The JS runtime is full of checks for is<NumberObject> and friends. They were showing up in a Speedometer profile as ~1% spent in dynamic_cast, and this basically chops that down to nothing.
2025-03-25 08:34:06 +00:00
virtual bool is_error() const { return false; }
virtual bool is_date() const { return false; }
virtual bool is_number_object() const { return false; }
virtual bool is_boolean_object() const { return false; }
virtual bool is_regexp_object() const { return false; }
virtual bool is_bigint_object() const { return false; }
LibJS: Add fast_is<T> for StringObject and GlobalObject Both of these are quite hot in profiles.
2021-03-19 11:28:44 +01:00
virtual bool is_string_object() const { return false; }
virtual bool is_global_object() const { return false; }
LibJS: Add a bunch of fast_is<T> to avoid slow RTTI in hot code
2021-06-13 11:23:23 +02:00
virtual bool is_proxy_object() const { return false; }
virtual bool is_native_function() const { return false; }
LibJS: Rename OrdinaryFunctionObject to ECMAScriptFunctionObject The old name is the result of the perhaps somewhat confusingly named abstract operation OrdinaryFunctionCreate(), which creates an "ordinary object" (https://tc39.es/ecma262/#ordinary-object) in contrast to an "exotic object" (https://tc39.es/ecma262/#exotic-object). However, the term "Ordinary Function" is not used anywhere in the spec, instead the created object is referred to as an "ECMAScript Function Object" (https://tc39.es/ecma262/#sec-ecmascript-function-objects), so let's call it that. The "ordinary" vs. "exotic" distinction is important because there are also "Built-in Function Objects", which can be either implemented as ordinary ECMAScript function objects, or as exotic objects (our NativeFunction). More work needs to be done to move a lot of infrastructure to ECMAScriptFunctionObject in order to make FunctionObject nothing more than an interface for objects that implement [[Call]] and optionally [[Construct]].
2021-09-24 22:40:38 +02:00
virtual bool is_ecmascript_function_object() const { return false; }
LibJS: Add fast_is<ArrayIterator>()
2023-12-08 12:37:40 +01:00
virtual bool is_array_iterator() const { return false; }
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: Implement support for the [[IsHTMLDDA]] internal slot Best regards from Annex B and document.all :^)
2021-06-20 17:08:29 +01:00
// B.3.7 The [[IsHTMLDDA]] Internal Slot, https://tc39.es/ecma262/#sec-IsHTMLDDA-internal-slot
virtual bool is_htmldda() const { return false; }
LibJS: Make Object.prototype.toString() fully spec compliant - Fix evaluation order: IsArray(O) should always be called and before Get(O, @@toStringTag), previously it was the other way around and IsArray would only be called if @@toStringTag is not a string - Add missing exception checks to both function calls - Add missing builtin tag for arguments object Also, while we're here: - Update variable names to match spec - Add spec step comments
2021-07-05 18:31:56 +01:00
bool has_parameter_map() const { return m_has_parameter_map; }
void set_has_parameter_map() { m_has_parameter_map = true; }
LibJS: Rename Cell::visit_children() => Cell::visit_edges() The GC heap is really a graph of cells, so "children" didn't quite feel appropriate here.
2020-11-28 14:33:36 +01:00
virtual void visit_edges(Cell::Visitor&) override;
LibJS: Add ObjectPrototype and implement hasOwnProperty() All Objects will now have ObjectPrototype as their prototype, unless overridden.
2020-03-15 15:25:43 +01:00
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
Value get_direct(size_t index) const { return m_storage[index]; }
LibJS: Add basic monomorphic caching for PutById property access This patch makes it possible for JS::Object::internal_set() to populate a CacheablePropertyMetadata, and uses this to implement a basic monomorphic cache for the most common form of property write access.
2023-11-08 20:51:26 +01:00
void put_direct(size_t index, Value value) { m_storage[index] = value; }
LibJS: Add Object::own_properties() convenience accessor
2020-03-26 12:19:01 +01:00
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
IndexedProperties const& indexed_properties() const { return m_indexed_properties; }
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
IndexedProperties& indexed_properties() { return m_indexed_properties; }
void set_indexed_property_elements(Vector<Value>&& values) { m_indexed_properties = IndexedProperties(move(values)); }
LibJS: Add a number-indexed property storage to all Objects Objects can have both named and indexed properties. Previously we kept all property names as strings. This patch separates named and indexed properties and splits them between Object::m_storage and m_elements. This allows us to do much faster array-style access using numeric indices. It also makes the Array class much less special, since all Objects now have number-indexed storage. :^)
2020-04-06 16:53:02 +02:00
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
Shape& shape() { return *m_shape; }
Shape const& shape() const { return *m_shape; }
LibJS: Cache access to properties found in prototype chain We already had fast access to own properties via shape-based IC. This patch extends the mechanism to properties on the prototype chain, using the "validity cell" technique from V8. - Prototype objects now have unique shape - Each prototype has an associated PrototypeChainValidity - When a prototype shape is mutated, every prototype shape "below" it in any prototype chain is invalidated. - Invalidation happens by marking the validity object as invalid, and then replacing it with a new validity object. - Property caches keep a pointer to the last seen valid validity. If there is no validity, or the validity is invalid, the cache misses and gets repopulated. This is very helpful when using JavaScript to access DOM objects, as we frequently have to traverse 4+ prototype objects before finding the property we're interested in on e.g EventTarget or Node.
2024-05-04 15:48:23 +02:00
void convert_to_prototype_if_needed();
LibJS: Add fast_is<T> for StringObject and GlobalObject Both of these are quite hot in profiles.
2021-03-19 11:28:44 +01:00
template<typename T>
bool fast_is() const = delete;
LibWeb+LibJS: Don't lazily construct web prototypes in cell constructors It's not safe to allocate from the GC heap while in the constructor of a GC heap cell. (Because if this ends up triggering a collection, we may end up trying to call through an uninitialized vtable). This was already done safely in the initialize() virtual in much of LibJS and LibWeb. This patch moves the logic for prototypes, mixins, and CSSStyleDeclaration as well. Fixes a long-standing GC crash that was pretty easy to reproduce by refreshing https://vercel.com/
2023-05-21 12:42:22 +02:00
void set_prototype(Object*);
LibJS: Add fast path for magical "length" property in LengthOfArrayLike For Array objects, we can avoid a generic Get here since we know it has magical "length" behavior anyway.
2023-12-08 12:34:42 +01:00
[[nodiscard]] bool has_magical_length_property() const { return m_has_magical_length_property; }
LibJS/JIT: Add fast path for GetById of Array.length Array.length is magical (since it has to reflect the number of elements in the object's property storage). We now handle it specially in jitted code, giving us a massive speed-up on Kraken/ai-astar.js (and probably many other things as well) :^)
2023-11-12 15:04:23 +01:00
LibJS: Devirtualize Object::is_typed_array()
2023-11-26 15:10:34 +01:00
[[nodiscard]] bool is_typed_array() const { return m_is_typed_array; }
void set_is_typed_array() { m_is_typed_array = true; }
LibJS: Expose const prototype getter in Object This is used in the temporal proposal in an assertion.
2024-01-05 21:18:55 +13:00
Object const* prototype() const { return shape().prototype(); }
LibJS: Clarify Object (base class) construction somewhat Divide the Object constructor into three variants: - The regular one (takes an Object& prototype) - One for use by GlobalObject - One for use by objects without a prototype (e.g ObjectPrototype)
2020-06-23 17:21:53 +02:00
protected:
enum class GlobalObjectTag { Tag };
enum class ConstructWithoutPrototypeTag { Tag };
LibJS: Remove Object(Object& prototype) footgun This constructor was easily confused with a copy constructor, and it was possible to accidentally copy-construct Objects in at least one way that we dicovered (via generic ThrowCompletionOr construction). This patch adds a mandatory ConstructWithPrototypeTag parameter to the constructor to disambiguate it.
2022-12-14 12:17:58 +01:00
enum class ConstructWithPrototypeTag { Tag };
LibJS: Hide all the constructors! Now that the GC allocator is able to invoke Cell subclass constructors directly via friendship, we no longer need to keep them public. :^)
2022-08-28 23:51:28 +02:00
LibJS+LibWeb: Devirtualize may_interfere_with_indexed_property_access()
2023-11-09 07:29:52 +00:00
Object(GlobalObjectTag, Realm&, MayInterfereWithIndexedPropertyAccess = MayInterfereWithIndexedPropertyAccess::No);
Object(ConstructWithoutPrototypeTag, Realm&, MayInterfereWithIndexedPropertyAccess = MayInterfereWithIndexedPropertyAccess::No);
Object(Realm&, Object* prototype, MayInterfereWithIndexedPropertyAccess = MayInterfereWithIndexedPropertyAccess::No);
Object(ConstructWithPrototypeTag, Object& prototype, MayInterfereWithIndexedPropertyAccess = MayInterfereWithIndexedPropertyAccess::No);
explicit Object(Shape&, MayInterfereWithIndexedPropertyAccess = MayInterfereWithIndexedPropertyAccess::No);
LibJS: Clarify Object (base class) construction somewhat Divide the Object constructor into three variants: - The regular one (takes an Object& prototype) - One for use by GlobalObject - One for use by objects without a prototype (e.g ObjectPrototype)
2020-06-23 17:21:53 +02:00
LibJS: Use a premade shape for normal function objects This avoids going through all the shape transitions when setting up the most common form of ESFO. This is extremely hot on Uber Eats, and this provides some relief.
2025-03-25 20:08:38 +00:00
void unsafe_set_shape(Shape&);
LibJS: Make Object.prototype.toString() fully spec compliant - Fix evaluation order: IsArray(O) should always be called and before Get(O, @@toStringTag), previously it was the other way around and IsArray would only be called if @@toStringTag is not a string - Add missing exception checks to both function calls - Add missing builtin tag for arguments object Also, while we're here: - Update variable names to match spec - Add spec step comments
2021-07-05 18:31:56 +01:00
// [[Extensible]]
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
bool m_is_extensible { true };
LibJS: Have Uint8ClampedArray delegate OOB accesses to JS::Object Uint8ClampedArray itself only cares about legitimate in-bounds accesses since that's what where the specialization happens.
2020-12-01 17:10:57 +01:00
LibJS: Make Object.prototype.toString() fully spec compliant - Fix evaluation order: IsArray(O) should always be called and before Get(O, @@toStringTag), previously it was the other way around and IsArray would only be called if @@toStringTag is not a string - Add missing exception checks to both function calls - Add missing builtin tag for arguments object Also, while we're here: - Update variable names to match spec - Add spec step comments
2021-07-05 18:31:56 +01:00
// [[ParameterMap]]
bool m_has_parameter_map { false };
LibJS/JIT: Add fast path for GetById of Array.length Array.length is magical (since it has to reflect the number of elements in the object's property storage). We now handle it specially in jitted code, giving us a massive speed-up on Kraken/ai-astar.js (and probably many other things as well) :^)
2023-11-12 15:04:23 +01:00
bool m_has_magical_length_property { false };
LibJS: Devirtualize Object::is_typed_array()
2023-11-26 15:10:34 +01:00
bool m_is_typed_array { false };
LibJS: Have Uint8ClampedArray delegate OOB accesses to JS::Object Uint8ClampedArray itself only cares about legitimate in-bounds accesses since that's what where the specialization happens.
2020-12-01 17:10:57 +01:00
private:
LibJS: Avoid pointless transitions and metadata lookups in storage_set() - Replace the misleading abuse of the m_transitions_enabled flag for the fast path without lookup with a new m_initialized boolean that's set either by Heap::allocate() after calling the Object's initialize(), or by the GlobalObject in its special initialize_global_object(). This makes it work regardless of the shape's uniqueness. - When we're adding a new property past the initialization phase, there's no need to do a second metadata lookup to retrieve the storage value offset - it's known to always be the shape's property count minus one. Also, instead of doing manual storage resizing and assignment via indexing, just use Vector::append(). - When we didn't add a new property but are overwriting an existing one, the property count and therefore storage value offset doesn't change, so we don't have to retrieve it either. As a result, Object::set_shape() is now solely responsible for updating the m_shape pointer and is not resizing storage anymore, so I moved it into the header.
2021-08-28 17:12:14 +01:00
void set_shape(Shape& shape) { m_shape = &shape; }
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
LibJS: Rewrite most of Object for spec compliance :^) This is a huge patch, I know. In hindsight this perhaps could've been done slightly more incremental, but I started and then fixed everything until it worked, and here we are. I tried splitting of some completely unrelated changes into separate commits, however. Anyway. This is a rewrite of most of Object, and by extension large parts of Array, Proxy, Reflect, String, TypedArray, and some other things. What we already had worked fine for about 90% of things, but getting the last 10% right proved to be increasingly difficult with the current code that sort of grew organically and is only very loosely based on the spec - this became especially obvious when we started fixing a large number of test262 failures. Key changes include: - 1:1 matching function names and parameters of all object-related functions, to avoid ambiguity. Previously we had things like put(), which the spec doesn't have - as a result it wasn't always clear which need to be used. - Better separation between object abstract operations and internal methods - the former are always the same, the latter can be overridden (and are therefore virtual). The internal methods (i.e. [[Foo]] in the spec) are now prefixed with 'internal_' for clarity - again, it was previously not always clear which AO a certain method represents, get() could've been both Get and [[Get]] (I don't know which one it was closer to right now). Note that some of the old names have been kept until all code relying on them is updated, but they are now simple wrappers around the closest matching standard abstract operation. - Simplifications of the storage layer: functions that write values to storage are now prefixed with 'storage_' to make their purpose clear, and as they are not part of the spec they should not contain any steps specified by it. Much functionality is now covered by the layers above it and was removed (e.g. handling of accessors, attribute checks). - PropertyAttributes has been greatly simplified, and is being replaced by PropertyDescriptor - a concept similar to the current implementation, but more aligned with the actual spec. See the commit message of the previous commit where it was introduced for details. - As a bonus, and since I had to look at the spec a whole lot anyway, I introduced more inline comments with the exact steps from the spec - this makes it super easy to verify correctness. - East-const all the things. As a result of all of this, things are much more correct but a bit slower now. Retaining speed wasn't a consideration at all, I have done no profiling of the new code - there might be low hanging fruits, which we can then harvest separately. Special thanks to Idan for helping me with this by tracking down bugs, updating everything outside of LibJS to work with these changes (LibWeb, Spreadsheet, HackStudio), as well as providing countless patches to fix regressions I introduced - there still are very few (we got it down to 5), but we also get many new passing test262 tests in return. :^) Co-authored-by: Idan Horowitz <idan.horowitz@gmail.com>
2021-07-04 18:14:16 +01:00
Object* prototype() { return shape().prototype(); }
LibJS+LibWeb: Devirtualize may_interfere_with_indexed_property_access()
2023-11-09 07:29:52 +00:00
bool m_may_interfere_with_indexed_property_access { false };
LibJS: Skip lazy intrinsic allocation check for objects without them Most JS::Objects don't have lazily-allocated intrinsic properties, so let's avoid doing hash lookups by putting a flag on JS::Object that tells us whether it's present in s_intrinsics. Takes CPU time spent in those hash lookups from 1-2.5% to nothing on various JS heavy pages.
2023-06-11 19:46:52 +02:00
// True if this object has lazily allocated intrinsic properties.
bool m_has_intrinsic_accessors { false };
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ptr<Shape> m_shape;
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
Vector<Value> m_storage;
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
IndexedProperties m_indexed_properties;
LibJS: Only allocate space for Object private elements if needed Most JavaScript objects don't have private elements, so this reduces the size of typical JS::Object instances by two pointers.
2021-12-08 09:38:31 +01:00
OwnPtr<Vector<PrivateElement>> m_private_elements; // [[PrivateElements]]
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