LibGC: Implement incremental garbage collection

[marcbutler]

Convert collector to run incrementally, using standard tricolor marking and a hybrid of Yuasa (SATB, deletion) and Dijkstra (insertion) write barriers that shade both old and new targets gray.

Marking and sweeping budgets specified in cells, and blocks respectively, and there has been no attempt to tune either.

This code is more than a proof-of-concept, but lacks refinement.

[jdahlin]

@marcbutler have you tried running the whole https://github.com/LadybirdBrowser/js-benchmarks/ with and without these changes? So we can see the performance impact of it in the individual tests.

[marcbutler]

@marcbutler have you tried running the whole https://github.com/LadybirdBrowser/js-benchmarks/ with and without these changes? So we can see the performance impact of it in the individual tests.

@jdahlin No I have not but I will look into doing so. I have only just got it working, and wanted to get feedback as early as possible.

I do not anticipate an improvement in performance. The incremental collector with the right tuning should smooth out collection pauses, but I suspect the write barriers overhead will reduce performance.

[ladybird-bot]

Hello!

One or more of the commit messages in this PR do not match the Ladybird code submission policy, please check the lint_commits CI job for more details on which commits were flagged and why.
Please do not close this PR and open another, instead modify your commit message(s) with git commit --amend and force push those changes to update this PR.

[awesomekling]

Hello! Thanks for posting this for early feedback.

This is an unusually broad and correctness-sensitive change set: it changes LibGC’s marking model, adds write barriers across a large number of LibJS mutation sites, changes weak/finalization behavior, and also reaches into the event loop and LibWeb.

Given that scope, I think the patch needs three things before it can be reviewed usefully:

1. A design writeup that explains the collector invariants and the tradeoffs behind the chosen barrier scheme, incremental sweep, root rescanning, weak/finalization semantics, and allocation coloring.

2. Validation that barrier coverage is complete, plus targeted tests for the new correctness-sensitive behavior.

3. Quantitative results: benchmark impact, pause-time measurements, and memory-usage changes.

Without that, it is hard to distinguish a promising prototype from a patch that only appears coherent at a high level.