beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-21 23:20:20 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
ladybird/Libraries/LibGC/Heap.h

210 lines
6.6 KiB
C
Raw Normal View History

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 18:23:58 +00:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 11:19:50 +00:00
* Copyright (c) 2020-2024, Andreas Kling <andreas@ladybird.org>
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 18:23:58 +00: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 08:24:48 +00:00
* SPDX-License-Identifier: BSD-2-Clause
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 18:23:58 +00: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 16:12:14 +00:00
#include <AK/Badge.h>
LibJS: Use a Function to indirectly let Heap visit VM's GC roots This allows the heap to mark cells that it needs to mark as roots without needing to directly reference the VM.
2024-11-14 07:17:33 +00:00
#include <AK/Function.h>
LibJS: Add Handle<T>, a strong C++ handle for keeping GC objects alive This is pretty heavy and unoptimized, but it will do the trick for now. Basically, Heap now has a HashTable<HandleImpl*> and you can call JS::make_handle(T*) to construct a Handle<T> that guarantees that the pointee will always survive GC until the Handle<T> is destroyed.
2020-03-18 19:03:17 +00:00
#include <AK/HashTable.h>
LibJS: Use IntrusiveList for keeping track of HandleImpls This allows us to remove a HashTable from heap and cuts down on some of the malloc traffic when creating handles.
2021-07-21 17:45:21 +00:00
#include <AK/IntrusiveList.h>
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 18:23:58 +00:00
#include <AK/Noncopyable.h>
#include <AK/NonnullOwnPtr.h>
LibJS: Make Heap own its own StackInfo instance While this does mean that we keep one copy of the stack info in the VM, and another in the Heap; keeping a separate instance removes one more instance of coupling between the heap and LibJS specific details.
2024-08-18 10:04:55 +00:00
#include <AK/StackInfo.h>
LibGC: Add Swift bindings to the GC heap This includes a protocol for creating LibGC Heap allocated Swift objects. Pay no attention to the Unmanaged shenanigans, they are all behind the curtain.
2024-11-16 21:58:28 +00:00
#include <AK/Swift.h>
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 18:23:58 +00:00
#include <AK/Types.h>
#include <AK/Vector.h>
LibJS: Add API for doing GC with a little debug log report at end You can now pass print_report=true to Heap::collect_garbage() and it will print out a little summary of the time spent, and counts of live vs freed cells and blocks.
2020-08-16 18:33:56 +00:00
#include <LibCore/Forward.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-14 15:01:23 +00:00
#include <LibGC/Cell.h>
#include <LibGC/CellAllocator.h>
#include <LibGC/ConservativeVector.h>
#include <LibGC/Forward.h>
#include <LibGC/HeapRoot.h>
#include <LibGC/Internals.h>
#include <LibGC/MarkedVector.h>
#include <LibGC/Root.h>
#include <LibGC/WeakContainer.h>
namespace GC {
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 18:23:58 +00:00
LibJS: Resolve a circular include problem between HeapBlock and Cell Cell::heap() and Cell::vm() needed to access member functions from HeapBlock, and wanted to be inline, so they were moved to VM.h. That approach will no longer work with VM.h not being included in every file (starting from the next commit), so this commit fixes that circular import issue by introducing secondary base classes to host the references to Heap and VM, respectively.
2023-07-09 16:35:02 +00:00
class Heap : public HeapBase {
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 18:23:58 +00:00
AK_MAKE_NONCOPYABLE(Heap);
AK_MAKE_NONMOVABLE(Heap);
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-14 15:01:23 +00:00
explicit Heap(void* private_data, AK::Function<void(HashMap<Cell*, GC::HeapRoot>&)> gather_embedder_roots);
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 18:23:58 +00:00
~Heap();
template<typename T, typename... Args>
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-14 15:01:23 +00:00
Ref<T> allocate(Args&&... args)
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 18:23:58 +00:00
{
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 08:45:05 +00:00
auto* memory = allocate_cell<T>();
LibJS: Defer GC during cell construction This stops us from trying to collect not fully constructed Cells, which's vtables are not fully initialized, which would cause issues during GC.
2023-09-23 11:47:16 +00:00
defer_gc();
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 18:23:58 +00:00
new (memory) T(forward<Args>(args)...);
LibJS: Defer GC during cell construction This stops us from trying to collect not fully constructed Cells, which's vtables are not fully initialized, which would cause issues during GC.
2023-09-23 11:47:16 +00:00
undefer_gc();
LibJS: Convert Heap::allocate{,_without_realm}() to NonnullGCPtr
2022-12-14 17:40:33 +00:00
return *static_cast<T*>(memory);
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 18:23:58 +00:00
}
LibJS: Always collect all garbage when destroying Heap When the Heap is going down, it's our last chance to run destructors, so add a separate collector mode where we simply skip over the marking phase and go directly to sweeping. This causes everything to get swept and all live cells get destroyed. This way, valgrind reports 0 leaks on exit. :^)
2020-03-23 13:11:19 +00:00
enum class CollectionType {
CollectGarbage,
CollectEverything,
};
LibJS: Add API for doing GC with a little debug log report at end You can now pass print_report=true to Heap::collect_garbage() and it will print out a little summary of the time spent, and counts of live vs freed cells and blocks.
2020-08-16 18:33:56 +00:00
void collect_garbage(CollectionType = CollectionType::CollectGarbage, bool print_report = false);
LibJS+LibWebView+WebContent+Ladybird: Output GC-graph into a file Instead of displaying a massive JSON in stdout, it's more practical to save the GC-graph to a file.
2023-12-12 12:25:06 +00:00
AK::JsonObject dump_graph();
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 18:23:58 +00:00
LibJS+js: Add a debug option (js -g) to GC after every allocation This is very useful for discovering collector bugs.
2020-03-16 18:18:46 +00:00
bool should_collect_on_every_allocation() const { return m_should_collect_on_every_allocation; }
void set_should_collect_on_every_allocation(bool b) { m_should_collect_on_every_allocation = b; }
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-14 15:01:23 +00:00
void did_create_root(Badge<RootImpl>, RootImpl&);
void did_destroy_root(Badge<RootImpl>, RootImpl&);
LibJS: Add Handle<T>, a strong C++ handle for keeping GC objects alive This is pretty heavy and unoptimized, but it will do the trick for now. Basically, Heap now has a HashTable<HandleImpl*> and you can call JS::make_handle(T*) to construct a Handle<T> that guarantees that the pointee will always survive GC until the Handle<T> is destroyed.
2020-03-18 19:03:17 +00:00
LibJS: Add MarkedVector<T> This abstracts a vector of Cell* with a strongly typed span() accessor that gives you Span<T*> instead of Span<Cell*>. It is intended to replace MarkedValueList in situations where you only need to store pointers to Cell (or an even more specific type of Cell). The API can definitely be improved, it's just the bare basics for now.
2021-12-16 17:54:06 +00:00
void did_create_marked_vector(Badge<MarkedVectorBase>, MarkedVectorBase&);
void did_destroy_marked_vector(Badge<MarkedVectorBase>, MarkedVectorBase&);
LibJS: Add ConservativeVector<T> This works very similarly to MarkedVector<T>, but instead of expecting T to be Value or a GC-allocated pointer type, T can be anything. Every pointer-sized value in the vector's storage will be checked during conservative root scanning. In other words, this allows you to put something like this in a ConservativeVector<Foo> and it will be protected from GC: struct Foo { i64 number; Value some_value; GCPtr<Object> some_object; };
2024-02-22 12:18:31 +00:00
void did_create_conservative_vector(Badge<ConservativeVectorBase>, ConservativeVectorBase&);
void did_destroy_conservative_vector(Badge<ConservativeVectorBase>, ConservativeVectorBase&);
LibJS: Generify the garbage collector's weak container notifications This will allow us to use the same interface for other JS weak containers like the WeakMap & WeakRef.
2021-06-12 02:23:33 +00:00
void did_create_weak_container(Badge<WeakContainer>, WeakContainer&);
void did_destroy_weak_container(Badge<WeakContainer>, WeakContainer&);
LibJS: Notify WeakSets when heap cells are sweeped This is an implementation of the following optional optimization: https://tc39.es/ecma262/#sec-weakref-execution
2021-06-09 17:10:47 +00:00
LibJS: Make Heap aware of all CellAllocators Also add a link from HeapBlock to their owning CellAllocator. This fixes an issue where the Heap would skip over non-size-based cell allocators.
2023-12-23 14:13:51 +00:00
void register_cell_allocator(Badge<CellAllocator>, CellAllocator&);
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-14 15:01:23 +00:00
void uproot_cell(Cell* cell);
Revert "LibJS: Remove "uprooting" mechanism from garbage collector" This reverts commit 6232ad3a0d44a3833c476d37bf4084d39a10a74b. Unfortunately this introduced some flakiness on CI, so it wasn't quite this simple.
2023-07-22 04:53:22 +00:00
LibGC: Expose deferred state publicly, annotate DeferGC for Swift While we don't want arbitrary callers deferring GC, we do want deferral to be available to the Swift. In order for Swift to understand the RAII nature of DeferGC, we need to mark it as non-copyable.
2024-11-17 01:45:19 +00:00
bool is_gc_deferred() const { return m_gc_deferrals > 0; }
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 18:23:58 +00:00
private:
AK+LibJS: Introduce `JS::HeapFunction` This change introduces HeapFunction, which is intended to be used as a replacement for SafeFunction. The new type behaves like a regular GC-allocated object, which means it needs to be visited from visit_edges, and unlike SafeFunction, it does not create new roots for captured parameters. Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-08-18 16:21:33 +00:00
friend class MarkingVisitor;
friend class GraphConstructorVisitor;
LibJS: Make GC deferral friendship based
2023-09-23 11:44:13 +00:00
friend class DeferGC;
LibGC: Add a ForeignCell class for ownership of non-C++ objects This will allow us to use the GC to manage the lifetime of objects that are not C++ objects, such as Swift objects. In the future we could expand this cursed FFI to other languages as well.
2024-11-16 21:56:27 +00:00
friend class ForeignCell;
LibJS: Make GC deferral friendship based
2023-09-23 11:44:13 +00:00
void defer_gc();
void undefer_gc();
AK+LibJS: Introduce `JS::HeapFunction` This change introduces HeapFunction, which is intended to be used as a replacement for SafeFunction. The new type behaves like a regular GC-allocated object, which means it needs to be visited from visit_edges, and unlike SafeFunction, it does not create new roots for captured parameters. Co-Authored-By: Andreas Kling <kling@serenityos.org>
2023-08-18 16:21:33 +00: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-14 15:01:23 +00:00
static bool cell_must_survive_garbage_collection(Cell const&);
LibJS: Add Cell::must_survive_garbage_collection() mechanism This allows cells to prevent themselves from being garbage collected, even when there are no references to them.
2022-10-24 10:37:54 +00:00
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 08:45:05 +00:00
template<typename T>
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-14 15:01:23 +00:00
Cell* allocate_cell()
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 08:45:05 +00:00
{
will_allocate(sizeof(T));
LibJS: Actually invoke the type-isolating cell allocators Due to a `requires` mistake, we were always using the fallback size-based cell allocators. Also, now that we start using them, make them NeverDestroyed so we don't try to deallocate them on program exit.
2023-12-23 19:00:21 +00:00
if constexpr (requires { T::cell_allocator.allocator.get().allocate_cell(*this); }) {
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 08:45:05 +00:00
if constexpr (IsSame<T, typename decltype(T::cell_allocator)::CellType>) {
LibJS: Actually invoke the type-isolating cell allocators Due to a `requires` mistake, we were always using the fallback size-based cell allocators. Also, now that we start using them, make them NeverDestroyed so we don't try to deallocate them on program exit.
2023-12-23 19:00:21 +00:00
return T::cell_allocator.allocator.get().allocate_cell(*this);
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 08:45:05 +00:00
}
}
return allocator_for_size(sizeof(T)).allocate_cell(*this);
}
void will_allocate(size_t);
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 18:23:58 +00:00
LibJS: Early reject pointers outside of allocated blocks range in GC This change adds a check to discard pointers that are lower than the minimum address of all allocated blocks or higher than the maximum address of all blocks. By doing this we avoid executing plenty of set() operations on the HashMap in the add_possible_value(). With this change gather_conservative_roots() run 10x times faster in Speedometer React-Redux-TodoMVC test.
2023-09-29 17:14:11 +00:00
void find_min_and_max_block_addresses(FlatPtr& min_address, FlatPtr& max_address);
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-14 15:01:23 +00:00
void gather_roots(HashMap<Cell*, HeapRoot>&);
void gather_conservative_roots(HashMap<Cell*, HeapRoot>&);
LibJS: Early reject pointers outside of allocated blocks range in GC This change adds a check to discard pointers that are lower than the minimum address of all allocated blocks or higher than the maximum address of all blocks. By doing this we avoid executing plenty of set() operations on the HashMap in the add_possible_value(). With this change gather_conservative_roots() run 10x times faster in Speedometer React-Redux-TodoMVC test.
2023-09-29 17:14:11 +00:00
void gather_asan_fake_stack_roots(HashMap<FlatPtr, HeapRoot>&, FlatPtr, FlatPtr min_block_address, FlatPtr max_block_address);
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-14 15:01:23 +00:00
void mark_live_cells(HashMap<Cell*, HeapRoot> const& live_cells);
LibJS: Add a finalization pass to the garbage collector Doing things in the destructor of a GC-allocated object isn't always safe, in case it involves accessing other GC-allocated objects. If they were already swept by GC, we'd be poking into freed memory. This patch adds a separate finalization pass where GC calls finalize() on every unmarked cell that's about to be deleted. It's safe to access other GC objects in finalize(), even if they're also unmarked.
2022-10-20 16:35:19 +00:00
void finalize_unmarked_cells();
Everywhere: Run clang-format
2022-04-01 17:58:27 +00:00
void sweep_dead_cells(bool print_report, Core::ElapsedTimer const&);
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 18:23:58 +00:00
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 08:45:05 +00:00
ALWAYS_INLINE CellAllocator& allocator_for_size(size_t cell_size)
{
// FIXME: Use binary search?
LibJS: Make Heap aware of all CellAllocators Also add a link from HeapBlock to their owning CellAllocator. This fixes an issue where the Heap would skip over non-size-based cell allocators.
2023-12-23 14:13:51 +00:00
for (auto& allocator : m_size_based_cell_allocators) {
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 08:45:05 +00:00
if (allocator->cell_size() >= cell_size)
return *allocator;
}
LibJS: Make Heap aware of all CellAllocators Also add a link from HeapBlock to their owning CellAllocator. This fixes an issue where the Heap would skip over non-size-based cell allocators.
2023-12-23 14:13:51 +00:00
dbgln("Cannot get CellAllocator for cell size {}, largest available is {}!", cell_size, m_size_based_cell_allocators.last()->cell_size());
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 08:45:05 +00:00
VERIFY_NOT_REACHED();
}
LibJS: Split Heap into per-cell-size allocators Instead of keeping all the HeapBlocks in one big list, we now split it into two levels: - Heap has a set of Allocators, each with a specific cell size. - Allocators have two lists of blocks, "full" and "usable". Allocating a new cell no longer has to scan the entire set of blocks, but instead just needs to find the right allocator and then pop a cell from its freelist. If all the blocks in the allocator are full, a new block will be created. Blocks are moved from the "full" to "usable" list after sweeping has determined that they are not completely empty and not completely full. There are certainly many ways we can improve on this. This patch is mostly about getting the new allocator architecture in place. :^)
2020-10-06 16:50:47 +00:00
template<typename Callback>
void for_each_block(Callback callback)
{
LibJS: Make Heap aware of all CellAllocators Also add a link from HeapBlock to their owning CellAllocator. This fixes an issue where the Heap would skip over non-size-based cell allocators.
2023-12-23 14:13:51 +00:00
for (auto& allocator : m_all_cell_allocators) {
if (allocator.for_each_block(callback) == IterationDecision::Break)
LibJS: Split Heap into per-cell-size allocators Instead of keeping all the HeapBlocks in one big list, we now split it into two levels: - Heap has a set of Allocators, each with a specific cell size. - Allocators have two lists of blocks, "full" and "usable". Allocating a new cell no longer has to scan the entire set of blocks, but instead just needs to find the right allocator and then pop a cell from its freelist. If all the blocks in the allocator are full, a new block will be created. Blocks are moved from the "full" to "usable" list after sweeping has determined that they are not completely empty and not completely full. There are certainly many ways we can improve on this. This patch is mostly about getting the new allocator architecture in place. :^)
2020-10-06 16:50:47 +00:00
return;
}
}
LibJS: Improve garbage collection trigger condition This patch triggers the collector when allocated memory doubles instead of every 100k allocations. Which can almost half (reduce by ~48%) the time spent on collection when loading google-maps. This dynamic approach is inspired by some other GCs like Golang's and Lua's and improves performance in memory heavy applications because marking must visit old objects which will dominate the marking phase if the GC is invoked too often. This commit also improves the Octane Splay benchmark and almost doubles it :^)
2023-08-08 17:50:32 +00:00
static constexpr size_t GC_MIN_BYTES_THRESHOLD { 4 * 1024 * 1024 };
size_t m_gc_bytes_threshold { GC_MIN_BYTES_THRESHOLD };
size_t m_allocated_bytes_since_last_gc { 0 };
LibJS: Do a garbage collection every N allocations (N=10'000) To prevent the heap from growing infinitely large, we now do a full GC every 10'000 allocations. :^)
2020-04-06 10:36:49 +00:00
LibJS+js: Add a debug option (js -g) to GC after every allocation This is very useful for discovering collector bugs.
2020-03-16 18:18:46 +00:00
bool m_should_collect_on_every_allocation { false };
LibJS: Make Heap aware of all CellAllocators Also add a link from HeapBlock to their owning CellAllocator. This fixes an issue where the Heap would skip over non-size-based cell allocators.
2023-12-23 14:13:51 +00:00
Vector<NonnullOwnPtr<CellAllocator>> m_size_based_cell_allocators;
CellAllocator::List m_all_cell_allocators;
LibJS: Use IntrusiveList for keeping track of HandleImpls This allows us to remove a HashTable from heap and cuts down on some of the malloc traffic when creating handles.
2021-07-21 17:45:21 +00: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-14 15:01:23 +00:00
RootImpl::List m_roots;
LibJS: Add MarkedVector<T> This abstracts a vector of Cell* with a strongly typed span() accessor that gives you Span<T*> instead of Span<Cell*>. It is intended to replace MarkedValueList in situations where you only need to store pointers to Cell (or an even more specific type of Cell). The API can definitely be improved, it's just the bare basics for now.
2021-12-16 17:54:06 +00:00
MarkedVectorBase::List m_marked_vectors;
LibJS: Add ConservativeVector<T> This works very similarly to MarkedVector<T>, but instead of expecting T to be Value or a GC-allocated pointer type, T can be anything. Every pointer-sized value in the vector's storage will be checked during conservative root scanning. In other words, this allows you to put something like this in a ConservativeVector<Foo> and it will be protected from GC: struct Foo { i64 number; Value some_value; GCPtr<Object> some_object; };
2024-02-22 12:18:31 +00:00
ConservativeVectorBase::List m_conservative_vectors;
LibJS: Use IntrusiveList for keeping track of WeakContainers
2021-07-21 17:57:41 +00:00
WeakContainer::List m_weak_containers;
LibJS: Notify WeakSets when heap cells are sweeped This is an implementation of the following optional optimization: https://tc39.es/ecma262/#sec-weakref-execution
2021-06-09 17:10:47 +00: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-14 15:01:23 +00:00
Vector<Ptr<Cell>> m_uprooted_cells;
Revert "LibJS: Remove "uprooting" mechanism from garbage collector" This reverts commit 6232ad3a0d44a3833c476d37bf4084d39a10a74b. Unfortunately this introduced some flakiness on CI, so it wasn't quite this simple.
2023-07-22 04:53:22 +00:00
LibJS: Add DeferGC, a RAII way to prevent GC temporarily
2020-04-19 09:30:47 +00:00
size_t m_gc_deferrals { 0 };
bool m_should_gc_when_deferral_ends { false };
LibJS: Assert if garbage collection is restarted while ongoing We can't GC while we're already in GC. Assert if this happens.
2020-09-21 12:35:19 +00:00
bool m_collecting_garbage { false };
LibJS: Make Heap own its own StackInfo instance While this does mean that we keep one copy of the stack info in the VM, and another in the Heap; keeping a separate instance removes one more instance of coupling between the heap and LibJS specific details.
2024-08-18 10:04:55 +00:00
StackInfo m_stack_info;
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-14 15:01:23 +00:00
AK::Function<void(HashMap<Cell*, GC::HeapRoot>&)> m_gather_embedder_roots;
LibGC: Add Swift bindings to the GC heap This includes a protocol for creating LibGC Heap allocated Swift objects. Pay no attention to the Unmanaged shenanigans, they are all behind the curtain.
2024-11-16 21:58:28 +00:00
} SWIFT_IMMORTAL_REFERENCE;
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 18:23:58 +00: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-14 15:01:23 +00:00
inline void Heap::did_create_root(Badge<RootImpl>, RootImpl& impl)
LibJS: Move Heap intrusive list manipulation inline The functions for registering and unregistering MarkedVector, Handle, etc. were quite prominent in benchmark profiles. 4% speed-up on the entire Kraken benchmark :^) (including: 7% speed-up on Kraken/imaging-gaussian-blur.js, the current slowest subtest)
2023-10-07 07:15:09 +00: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-14 15:01:23 +00:00
VERIFY(!m_roots.contains(impl));
m_roots.append(impl);
LibJS: Move Heap intrusive list manipulation inline The functions for registering and unregistering MarkedVector, Handle, etc. were quite prominent in benchmark profiles. 4% speed-up on the entire Kraken benchmark :^) (including: 7% speed-up on Kraken/imaging-gaussian-blur.js, the current slowest subtest)
2023-10-07 07:15:09 +00: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-14 15:01:23 +00:00
inline void Heap::did_destroy_root(Badge<RootImpl>, RootImpl& impl)
LibJS: Move Heap intrusive list manipulation inline The functions for registering and unregistering MarkedVector, Handle, etc. were quite prominent in benchmark profiles. 4% speed-up on the entire Kraken benchmark :^) (including: 7% speed-up on Kraken/imaging-gaussian-blur.js, the current slowest subtest)
2023-10-07 07:15:09 +00: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-14 15:01:23 +00:00
VERIFY(m_roots.contains(impl));
m_roots.remove(impl);
LibJS: Move Heap intrusive list manipulation inline The functions for registering and unregistering MarkedVector, Handle, etc. were quite prominent in benchmark profiles. 4% speed-up on the entire Kraken benchmark :^) (including: 7% speed-up on Kraken/imaging-gaussian-blur.js, the current slowest subtest)
2023-10-07 07:15:09 +00:00
}
inline void Heap::did_create_marked_vector(Badge<MarkedVectorBase>, MarkedVectorBase& vector)
{
VERIFY(!m_marked_vectors.contains(vector));
m_marked_vectors.append(vector);
}
inline void Heap::did_destroy_marked_vector(Badge<MarkedVectorBase>, MarkedVectorBase& vector)
{
VERIFY(m_marked_vectors.contains(vector));
m_marked_vectors.remove(vector);
}
LibJS: Add ConservativeVector<T> This works very similarly to MarkedVector<T>, but instead of expecting T to be Value or a GC-allocated pointer type, T can be anything. Every pointer-sized value in the vector's storage will be checked during conservative root scanning. In other words, this allows you to put something like this in a ConservativeVector<Foo> and it will be protected from GC: struct Foo { i64 number; Value some_value; GCPtr<Object> some_object; };
2024-02-22 12:18:31 +00:00
inline void Heap::did_create_conservative_vector(Badge<ConservativeVectorBase>, ConservativeVectorBase& vector)
{
VERIFY(!m_conservative_vectors.contains(vector));
m_conservative_vectors.append(vector);
}
inline void Heap::did_destroy_conservative_vector(Badge<ConservativeVectorBase>, ConservativeVectorBase& vector)
{
VERIFY(m_conservative_vectors.contains(vector));
m_conservative_vectors.remove(vector);
}
LibJS: Move Heap intrusive list manipulation inline The functions for registering and unregistering MarkedVector, Handle, etc. were quite prominent in benchmark profiles. 4% speed-up on the entire Kraken benchmark :^) (including: 7% speed-up on Kraken/imaging-gaussian-blur.js, the current slowest subtest)
2023-10-07 07:15:09 +00:00
inline void Heap::did_create_weak_container(Badge<WeakContainer>, WeakContainer& set)
{
VERIFY(!m_weak_containers.contains(set));
m_weak_containers.append(set);
}
inline void Heap::did_destroy_weak_container(Badge<WeakContainer>, WeakContainer& set)
{
VERIFY(m_weak_containers.contains(set));
m_weak_containers.remove(set);
}
LibJS: Make Heap aware of all CellAllocators Also add a link from HeapBlock to their owning CellAllocator. This fixes an issue where the Heap would skip over non-size-based cell allocators.
2023-12-23 14:13:51 +00:00
inline void Heap::register_cell_allocator(Badge<CellAllocator>, CellAllocator& allocator)
{
m_all_cell_allocators.append(allocator);
}
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 18:23:58 +00:00
}
Reference in a new issue Copy permalink