Using ensure_capacity() was a mistake, as that API is for specifying an
exact needed capacity, while grow_capacity() is for growing at a
reasonable rate.
Amusingly, we ended up with very different behavior on macOS and Linux
here, since ensure_capacity() calls kmalloc_good_size() which quantizes
to malloc bucket sizes on macOS, but is effectively a no-op on Linux.
Extreme slowdown on Linux caught by GarBench/marking-stress.js
When passing a Vector<JS::Value> to the MarkingVisitor, we were
iterating over the vector and visiting one value at a time. This led
to a very inefficient way of building up the GC's work queue.
By adding a new visit_impl() virtual to Cell::Visitor, we can now
grow the work queue capacity once, and then add without incrementally
growing the storage.
Instead of checking if every single cell overrides the "must survive GC"
virtual, we can make this a HeapBlock level thing.
This avoids almost an entire GC heap traversal during the mark phase.
Post-GC tasks may trigger another GC, and things got very confusing
when that happened. Just dump all stats before running tasks.
Also add a separate Heap function to run these tasks. This makes
backtraces much easier to understand.
This had two fatal bugs:
1. We didn't actually mark the cell that must survive GC, we only
visited its edges.
2. Worse, we didn't actually mark anything at all! We just added
cells to MarkingVisitor's work queue, but this happened after
the work queue had already been processed.
This commit fixes these issues by moving the "must survive" pass
earlier in the mark phase.
Before this change, we'd use the system page size as the HeapBlock
size. This caused it to vary on different platforms, going as low
as 4 KiB on most Linux systems.
To make this work, we now use posix_memalign() to ensure we get
size-aligned allocations on every platform.
Also nice: HeapBlock::BLOCK_SIZE is now a constant.
In our process architecture, there's only ever one JS::VM per process.
This allows us to have a VM::the() singleton getter that optimizes
down to a single global access everywhere.
Seeing 1-2% speed-up on all JS benchmarks from this.
This is a weak pointer that integrates with the garbage collector.
It has a number of differences compared to AK::WeakPtr, including:
- The "control block" is allocated from a well-packed WeakBlock owned by
the GC heap, not just a generic malloc allocation.
- Pointers to dead cells are nulled out by the garbage collector
immediately before running destructors.
- It works on any GC::Cell derived type, meaning you don't have to
inherit from AK::Weakable for the ability to be weakly referenced.
- The Weak always points to a control block, even when "null" (it then
points to a null WeakImpl), which means one less null check when
chasing pointers.
This is a GC-aware wrapper around AK::HashMap. Entry values are treated
as GC roots, much like the GC::RootVector we already had.
We also provide GC::OrderedRootHashMap as a convenience.
Previously, we would only keep the cell that must survive alive, but
none of it's edges.
This cropped up with a GC UAF in must_survive_garbage_collection of
WebSocket in .NET's SignalR frontend implementation, where an
out-of-scope WebSocket had it's underlying EventTarget properties
garbage collected, and must_survive_garbage_collection read from the
destroyed EventTarget properties.
See: https://github.com/dotnet/aspnetcore/blob/main/src/SignalR/clients/ts/signalr/src/WebSocketTransport.ts#L81
Found on https://www.formula1.com/ during a live session.
Co-Authored-By: Tim Flynn <trflynn89@pm.me>
Before this change, it was possible for a second GC to get triggered
in the middle of a first GC, due to allocations happening in the
FinalizationRegistry cleanup host hook. To avoid this causing problems,
we add a "post-GC task" mechanism and use that to invoke the host hook
once all other GC activity is finished, and we've unset the "collecting
garbage" flag.
Note that the test included here only fails reliably when running with
the -g flag (collect garbage after each allocation).
Fixes#3051
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 14:49:20 +01:00
Renamed from Libraries/LibJS/Heap/Heap.cpp (Browse further)
