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/Libraries/LibJS/Runtime/AsyncFromSyncIterator.cpp

34 lines
995 B
C++
Raw Normal View History

LibJS: Add AsyncFromSyncIteratorPrototype and Async-From-Sync instances Until we have actual iterator records we have to store the sync iterator as the raw object.
2021-11-23 15:01:35 +01:00
/*
* Copyright (c) 2021, David Tuin <davidot@serenityos.org>
LibJS: Make intrinsics getters return NonnullGCPtr Some of these are allocated upon initialization of the intrinsics, and some lazily, but in neither case the getters actually return a nullptr. This saves us a whole bunch of pointer dereferences (as NonnullGCPtr has an `operator T&()`), and also has the interesting side effect of forcing us to explicitly use the FunctionObject& overload of call(), as passing a NonnullGCPtr is ambigous - it could implicitly be turned into a Value _or_ a FunctionObject& (so we have to dereference manually).
2023-04-13 00:47:15 +02:00
* Copyright (c) 2022-2023, Linus Groh <linusg@serenityos.org>
LibJS: Add AsyncFromSyncIteratorPrototype and Async-From-Sync instances Until we have actual iterator records we have to store the sync iterator as the raw object.
2021-11-23 15:01:35 +01:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#include <LibJS/Runtime/AsyncFromSyncIterator.h>
#include <LibJS/Runtime/AsyncFromSyncIteratorPrototype.h>
#include <LibJS/Runtime/GlobalObject.h>
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
GC_DEFINE_ALLOCATOR(AsyncFromSyncIterator);
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
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::Ref<AsyncFromSyncIterator> AsyncFromSyncIterator::create(Realm& realm, GC::Ref<IteratorRecord> sync_iterator_record)
LibJS: Add AsyncFromSyncIteratorPrototype and Async-From-Sync instances Until we have actual iterator records we have to store the sync iterator as the raw object.
2021-11-23 15:01:35 +01:00
{
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T> The main motivation behind this is to remove JS specifics of the Realm from the implementation of the Heap. As a side effect of this change, this is a bit nicer to read than the previous approach, and in my opinion, also makes it a little more clear that this method is specific to a JavaScript Realm.
2024-11-14 05:50:17 +13:00
return realm.create<AsyncFromSyncIterator>(realm, sync_iterator_record);
LibJS: Add AsyncFromSyncIteratorPrototype and Async-From-Sync instances Until we have actual iterator records we have to store the sync iterator as the raw object.
2021-11-23 15:01:35 +01:00
}
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
AsyncFromSyncIterator::AsyncFromSyncIterator(Realm& realm, GC::Ref<IteratorRecord> sync_iterator_record)
LibJS: Make intrinsics getters return NonnullGCPtr Some of these are allocated upon initialization of the intrinsics, and some lazily, but in neither case the getters actually return a nullptr. This saves us a whole bunch of pointer dereferences (as NonnullGCPtr has an `operator T&()`), and also has the interesting side effect of forcing us to explicitly use the FunctionObject& overload of call(), as passing a NonnullGCPtr is ambigous - it could implicitly be turned into a Value _or_ a FunctionObject& (so we have to dereference manually).
2023-04-13 00:47:15 +02:00
: Object(ConstructWithPrototypeTag::Tag, realm.intrinsics().async_from_sync_iterator_prototype())
LibJS: Add AsyncFromSyncIteratorPrototype and Async-From-Sync instances Until we have actual iterator records we have to store the sync iterator as the raw object.
2021-11-23 15:01:35 +01:00
, m_sync_iterator_record(sync_iterator_record)
{
}
void AsyncFromSyncIterator::visit_edges(Cell::Visitor& visitor)
{
LibJS+LibWeb: Add missing visit calls in visit_edges implementations
2023-03-21 10:08:44 -07:00
Base::visit_edges(visitor);
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
visitor.visit(m_sync_iterator_record);
LibJS: Add AsyncFromSyncIteratorPrototype and Async-From-Sync instances Until we have actual iterator records we have to store the sync iterator as the raw object.
2021-11-23 15:01:35 +01:00
}
}
Reference in a new issue Copy permalink