ladybird/Libraries/LibJS/Runtime/DisposableStack.cpp

/*
 * Copyright (c) 2022, David Tuin <davidot@serenityos.org>
 * Copyright (c) 2025, Tim Flynn <trflynn89@ladybird.org>
 *
 * SPDX-License-Identifier: BSD-2-Clause
 */

#include <LibJS/Runtime/DisposableStack.h>

namespace JS {

GC_DEFINE_ALLOCATOR(DisposableStack);

DisposableStack::DisposableStack(DisposeCapability dispose_capability, Object& prototype)
    : Object(ConstructWithPrototypeTag::Tag, prototype)
    , m_dispose_capability(move(dispose_capability))
{
}

void DisposableStack::visit_edges(Cell::Visitor& visitor)
{
    Base::visit_edges(visitor);
    m_dispose_capability.visit_edges(visitor);
}

}
LibJS: Add DisposableStack{, Prototype, Constructor} Since the async parts of the spec are not stage 3 at this point we don't add AsyncDisposableStack. 2022-12-21 11:48:14 +01:00			`/*`
			`* Copyright (c) 2022, David Tuin <davidot@serenityos.org>`
LibJS: Bring the explicit resource management implementation up to date While we don't yet have a working `using` implementation with our byte code, we can still keep our DisposableStack implementation up to date. The changes brought in here are all editorial, and set us up to start an AsyncDisposableStack implementation. 2025-01-16 16:51:26 -05:00			`* Copyright (c) 2025, Tim Flynn <trflynn89@ladybird.org>`
LibJS: Add DisposableStack{, Prototype, Constructor} Since the async parts of the spec are not stage 3 at this point we don't add AsyncDisposableStack. 2022-12-21 11:48:14 +01:00			`*`
			`* SPDX-License-Identifier: BSD-2-Clause`
			`*/`

			`#include <LibJS/Runtime/DisposableStack.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(DisposableStack);`
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
LibJS: Bring the explicit resource management implementation up to date While we don't yet have a working `using` implementation with our byte code, we can still keep our DisposableStack implementation up to date. The changes brought in here are all editorial, and set us up to start an AsyncDisposableStack implementation. 2025-01-16 16:51:26 -05:00			`DisposableStack::DisposableStack(DisposeCapability dispose_capability, Object& prototype)`
LibJS: Add DisposableStack{, Prototype, Constructor} Since the async parts of the spec are not stage 3 at this point we don't add AsyncDisposableStack. 2022-12-21 11:48:14 +01:00			`: Object(ConstructWithPrototypeTag::Tag, prototype)`
LibJS: Bring the explicit resource management implementation up to date While we don't yet have a working `using` implementation with our byte code, we can still keep our DisposableStack implementation up to date. The changes brought in here are all editorial, and set us up to start an AsyncDisposableStack implementation. 2025-01-16 16:51:26 -05:00			`, m_dispose_capability(move(dispose_capability))`
LibJS: Add DisposableStack{, Prototype, Constructor} Since the async parts of the spec are not stage 3 at this point we don't add AsyncDisposableStack. 2022-12-21 11:48:14 +01:00			`{`
			`}`

			`void DisposableStack::visit_edges(Cell::Visitor& visitor)`
			`{`
			`Base::visit_edges(visitor);`
LibJS: Bring the explicit resource management implementation up to date While we don't yet have a working `using` implementation with our byte code, we can still keep our DisposableStack implementation up to date. The changes brought in here are all editorial, and set us up to start an AsyncDisposableStack implementation. 2025-01-16 16:51:26 -05:00			`m_dispose_capability.visit_edges(visitor);`
LibJS: Add DisposableStack{, Prototype, Constructor} Since the async parts of the spec are not stage 3 at this point we don't add AsyncDisposableStack. 2022-12-21 11:48:14 +01:00			`}`

			`}`