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

90 lines
3 KiB
C
Raw Normal View History

LibJS: Implement proper Iterator records Instead of using plain objects as Iterator records, causes confusion about the object itself actually being its [[Iterator]] slot, and requires non-standard type conversion shenanigans fpr the [[NextValue]] and [[Done]] internal slots, implement a proper Iterator record struct and use it throughout. Also annotate the remaining Iterator AOs with spec comments while we're here.
2022-01-09 19:12:24 +01:00
/*
LibJS+LibWeb: Move IteratorOperations.h AOs to Iterator.h Rather than splitting the Iterator type and its AOs into two files, let's combine them into one file to match every other JS runtime object that we have.
2023-07-19 06:54:48 -04:00
* Copyright (c) 2020, Matthew Olsson <mattco@serenityos.org>
* Copyright (c) 2022-2023, Linus Groh <linusg@serenityos.org>
LibJS: Add an Iterator constructor and object The Iterator object cannot be constructed directly but can be subclassed or created with `Iterator.from` (not implemented here).
2023-06-24 10:01:04 -04:00
* Copyright (c) 2023, Tim Flynn <trflynn89@serenityos.org>
LibJS: Implement proper Iterator records Instead of using plain objects as Iterator records, causes confusion about the object itself actually being its [[Iterator]] slot, and requires non-standard type conversion shenanigans fpr the [[NextValue]] and [[Done]] internal slots, implement a proper Iterator record struct and use it throughout. Also annotate the remaining Iterator AOs with spec comments while we're here.
2022-01-09 19:12:24 +01:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
LibJS+LibWeb: Move IteratorOperations.h AOs to Iterator.h Rather than splitting the Iterator type and its AOs into two files, let's combine them into one file to match every other JS runtime object that we have.
2023-07-19 06:54:48 -04:00
#include <AK/Function.h>
#include <AK/Optional.h>
LibJS: Add an Iterator constructor and object The Iterator object cannot be constructed directly but can be subclassed or created with `Iterator.from` (not implemented here).
2023-06-24 10:01:04 -04:00
#include <LibJS/Runtime/Completion.h>
LibJS: Implement proper Iterator records Instead of using plain objects as Iterator records, causes confusion about the object itself actually being its [[Iterator]] slot, and requires non-standard type conversion shenanigans fpr the [[NextValue]] and [[Done]] internal slots, implement a proper Iterator record struct and use it throughout. Also annotate the remaining Iterator AOs with spec comments while we're here.
2022-01-09 19:12:24 +01:00
#include <LibJS/Runtime/Object.h>
#include <LibJS/Runtime/Value.h>
namespace JS {
LibJS: Add a spec link for Iterator Records This is an editorial change to the spec to strongly define this record: https://github.com/tc39/ecma262/commit/85d910c
2022-02-18 08:46:32 -05:00
// 7.4.1 Iterator Records, https://tc39.es/ecma262/#sec-iterator-records
LibJS: Stop converting between Object <-> IteratorRecord all the time This patch makes IteratorRecord an Object. Although it's not exposed to author code, this does allow us to store it in a VM register. Now that we can store it in a VM register, we don't need to convert it back and forth between IteratorRecord and Object when accessing it from bytecode. The big win here is avoiding 3 [[Get]] accesses on every iteration step of for..of loops. There are also a bunch of smaller efficiencies gained. 20% speed-up on this microbenchmark: function go(a) { for (const p of a) { } } const a = []; a.length = 1_000_000; go(a);
2023-12-07 10:44:41 +01:00
class IteratorRecord final : public Object {
JS_OBJECT(IteratorRecord, Object);
JS_DECLARE_ALLOCATOR(IteratorRecord);
public:
IteratorRecord(Realm& realm, GCPtr<Object> iterator, Value next_method, bool done)
: Object(ConstructWithoutPrototypeTag::Tag, realm)
, iterator(iterator)
, next_method(next_method)
, done(done)
{
}
LibJS+LibWeb: Wrap raw JS::Cell*/& fields in GCPtr/NonnullGCPtr
2023-02-26 16:09:02 -07:00
GCPtr<Object> iterator; // [[Iterator]]
Value next_method; // [[NextMethod]]
bool done { false }; // [[Done]]
LibJS: Stop converting between Object <-> IteratorRecord all the time This patch makes IteratorRecord an Object. Although it's not exposed to author code, this does allow us to store it in a VM register. Now that we can store it in a VM register, we don't need to convert it back and forth between IteratorRecord and Object when accessing it from bytecode. The big win here is avoiding 3 [[Get]] accesses on every iteration step of for..of loops. There are also a bunch of smaller efficiencies gained. 20% speed-up on this microbenchmark: function go(a) { for (const p of a) { } } const a = []; a.length = 1_000_000; go(a);
2023-12-07 10:44:41 +01:00
private:
virtual void visit_edges(Cell::Visitor&) override;
virtual bool is_iterator_record() const override { return true; }
LibJS: Implement proper Iterator records Instead of using plain objects as Iterator records, causes confusion about the object itself actually being its [[Iterator]] slot, and requires non-standard type conversion shenanigans fpr the [[NextValue]] and [[Done]] internal slots, implement a proper Iterator record struct and use it throughout. Also annotate the remaining Iterator AOs with spec comments while we're here.
2022-01-09 19:12:24 +01:00
};
LibJS: Stop converting between Object <-> IteratorRecord all the time This patch makes IteratorRecord an Object. Although it's not exposed to author code, this does allow us to store it in a VM register. Now that we can store it in a VM register, we don't need to convert it back and forth between IteratorRecord and Object when accessing it from bytecode. The big win here is avoiding 3 [[Get]] accesses on every iteration step of for..of loops. There are also a bunch of smaller efficiencies gained. 20% speed-up on this microbenchmark: function go(a) { for (const p of a) { } } const a = []; a.length = 1_000_000; go(a);
2023-12-07 10:44:41 +01:00
template<>
inline bool Object::fast_is<IteratorRecord>() const { return is_iterator_record(); }
LibJS: Add an Iterator constructor and object The Iterator object cannot be constructed directly but can be subclassed or created with `Iterator.from` (not implemented here).
2023-06-24 10:01:04 -04:00
class Iterator : public Object {
JS_OBJECT(Iterator, Object);
LibJS: Segregate GC-allocated objects by type This patch adds two macros to declare per-type allocators: - JS_DECLARE_ALLOCATOR(TypeName) - JS_DEFINE_ALLOCATOR(TypeName) When used, they add a type-specific CellAllocator that the Heap will delegate allocation requests to. The result of this is that GC objects of the same type always end up within the same HeapBlock, drastically reducing the ability to perform type confusion attacks. It also improves HeapBlock utilization, since each block now has cells sized exactly to the type used within that block. (Previously we only had a handful of block sizes available, and most GC allocations ended up with a large amount of slack in their tails.) There is a small performance hit from this, but I'm sure we can make up for it elsewhere. Note that the old size-based allocators still exist, and we fall back to them for any type that doesn't have its own CellAllocator.
2023-11-19 09:45:05 +01:00
JS_DECLARE_ALLOCATOR(Iterator);
LibJS: Add an Iterator constructor and object The Iterator object cannot be constructed directly but can be subclassed or created with `Iterator.from` (not implemented here).
2023-06-24 10:01:04 -04:00
public:
LibJS: Stop converting between Object <-> IteratorRecord all the time This patch makes IteratorRecord an Object. Although it's not exposed to author code, this does allow us to store it in a VM register. Now that we can store it in a VM register, we don't need to convert it back and forth between IteratorRecord and Object when accessing it from bytecode. The big win here is avoiding 3 [[Get]] accesses on every iteration step of for..of loops. There are also a bunch of smaller efficiencies gained. 20% speed-up on this microbenchmark: function go(a) { for (const p of a) { } } const a = []; a.length = 1_000_000; go(a);
2023-12-07 10:44:41 +01:00
static NonnullGCPtr<Iterator> create(Realm&, Object& prototype, NonnullGCPtr<IteratorRecord> iterated);
LibJS: Add an Iterator constructor and object The Iterator object cannot be constructed directly but can be subclassed or created with `Iterator.from` (not implemented here).
2023-06-24 10:01:04 -04:00
IteratorRecord const& iterated() const { return m_iterated; }
private:
LibJS: Stop converting between Object <-> IteratorRecord all the time This patch makes IteratorRecord an Object. Although it's not exposed to author code, this does allow us to store it in a VM register. Now that we can store it in a VM register, we don't need to convert it back and forth between IteratorRecord and Object when accessing it from bytecode. The big win here is avoiding 3 [[Get]] accesses on every iteration step of for..of loops. There are also a bunch of smaller efficiencies gained. 20% speed-up on this microbenchmark: function go(a) { for (const p of a) { } } const a = []; a.length = 1_000_000; go(a);
2023-12-07 10:44:41 +01:00
Iterator(Object& prototype, NonnullGCPtr<IteratorRecord> iterated);
LibJS: Add an Iterator constructor and object The Iterator object cannot be constructed directly but can be subclassed or created with `Iterator.from` (not implemented here).
2023-06-24 10:01:04 -04:00
explicit Iterator(Object& prototype);
LibJS: Stop converting between Object <-> IteratorRecord all the time This patch makes IteratorRecord an Object. Although it's not exposed to author code, this does allow us to store it in a VM register. Now that we can store it in a VM register, we don't need to convert it back and forth between IteratorRecord and Object when accessing it from bytecode. The big win here is avoiding 3 [[Get]] accesses on every iteration step of for..of loops. There are also a bunch of smaller efficiencies gained. 20% speed-up on this microbenchmark: function go(a) { for (const p of a) { } } const a = []; a.length = 1_000_000; go(a);
2023-12-07 10:44:41 +01:00
virtual void visit_edges(Cell::Visitor&) override;
NonnullGCPtr<IteratorRecord> m_iterated; // [[Iterated]]
LibJS: Add an Iterator constructor and object The Iterator object cannot be constructed directly but can be subclassed or created with `Iterator.from` (not implemented here).
2023-06-24 10:01:04 -04:00
};
LibJS+LibWeb: Move IteratorOperations.h AOs to Iterator.h Rather than splitting the Iterator type and its AOs into two files, let's combine them into one file to match every other JS runtime object that we have.
2023-07-19 06:54:48 -04:00
enum class IteratorHint {
Sync,
Async,
};
LibJS: Avoid creating String object wrappers in iterator helpers This is a normative change in the Iterator Helpers spec. See: https://github.com/tc39/proposal-iterator-helpers/commit/3e275cf
2023-07-12 15:45:05 -04:00
enum class StringHandling {
IterateStrings,
RejectStrings,
};
LibJS: Stop converting between Object <-> IteratorRecord all the time This patch makes IteratorRecord an Object. Although it's not exposed to author code, this does allow us to store it in a VM register. Now that we can store it in a VM register, we don't need to convert it back and forth between IteratorRecord and Object when accessing it from bytecode. The big win here is avoiding 3 [[Get]] accesses on every iteration step of for..of loops. There are also a bunch of smaller efficiencies gained. 20% speed-up on this microbenchmark: function go(a) { for (const p of a) { } } const a = []; a.length = 1_000_000; go(a);
2023-12-07 10:44:41 +01:00
ThrowCompletionOr<NonnullGCPtr<IteratorRecord>> get_iterator_from_method(VM&, Value, NonnullGCPtr<FunctionObject>);
ThrowCompletionOr<NonnullGCPtr<IteratorRecord>> get_iterator(VM&, Value, IteratorHint);
ThrowCompletionOr<NonnullGCPtr<IteratorRecord>> get_iterator_direct(VM&, Object&);
ThrowCompletionOr<NonnullGCPtr<IteratorRecord>> get_iterator_flattenable(VM&, Value, StringHandling);
LibJS+LibWeb: Move IteratorOperations.h AOs to Iterator.h Rather than splitting the Iterator type and its AOs into two files, let's combine them into one file to match every other JS runtime object that we have.
2023-07-19 06:54:48 -04:00
ThrowCompletionOr<NonnullGCPtr<Object>> iterator_next(VM&, IteratorRecord const&, Optional<Value> = {});
ThrowCompletionOr<GCPtr<Object>> iterator_step(VM&, IteratorRecord const&);
ThrowCompletionOr<bool> iterator_complete(VM&, Object& iterator_result);
ThrowCompletionOr<Value> iterator_value(VM&, Object& iterator_result);
Completion iterator_close(VM&, IteratorRecord const&, Completion);
Completion async_iterator_close(VM&, IteratorRecord const&, Completion);
NonnullGCPtr<Object> create_iterator_result_object(VM&, Value, bool done);
ThrowCompletionOr<MarkedVector<Value>> iterator_to_list(VM&, IteratorRecord const&);
using IteratorValueCallback = Function<Optional<Completion>(Value)>;
Completion get_iterator_values(VM&, Value iterable, IteratorValueCallback callback);
LibJS: Implement Iterator.from and the WrapForValidIteratorPrototype Iterator.from creates an Iterator from either an existing iterator or an iterator-like object. In the latter case, it sets the prototype of the returned iterator to WrapForValidIteratorPrototype to wrap around the iterator-like object's iteration methods.
2023-06-24 11:27:30 -04:00
LibJS: Implement proper Iterator records Instead of using plain objects as Iterator records, causes confusion about the object itself actually being its [[Iterator]] slot, and requires non-standard type conversion shenanigans fpr the [[NextValue]] and [[Done]] internal slots, implement a proper Iterator record struct and use it throughout. Also annotate the remaining Iterator AOs with spec comments while we're here.
2022-01-09 19:12:24 +01:00
}
Reference in a new issue Copy permalink