https://blog.ast.moe/en/tags/gc/Recent posts: GorimuchuHugohttps://blog.ast.moe/en/blog/2026-10-10/Sat, 10 Oct 2026 17:42:29 +0900https://blog.ast.moe/en/blog/2026-10-10/<p>We added DOM operations such as <code>before()</code> and <code>replaceChildren()</code> to Omoikane, along with <code>window.onerror</code> and notifications for unhandled Promise rejections. [<a href="https://github.com/ieee0824/omoikane/pull/1322">PR #1322</a>](<a href="https://github.com/ieee0824/omoikane/pull/1322">https://github.com/ieee0824/omoikane/pull/1322</a>) This is about that pull request. The initial issue was straightforward: the page lacked the APIs it normally calls. However, as we progressed with implementation and testing, we ended up fixing issues such as copying sibling lists when inserting HTML text, rebuilding the entire document after UTF‑16 appends, creating unnecessary iframe realms, and even addressing insufficient GC roots for Promises.</p>https://blog.ast.moe/en/blog/2026-10-08-2/Thu, 08 Oct 2026 21:52:45 +0900https://blog.ast.moe/en/blog/2026-10-08-2/<p>Opening <code>https://tokyo6.tokyo/</code> with Omoikane caused a bug where the script terminated with a SIGSEGV during execution. Issue #1223 (<a href="https://github.com/ieee0824/omoikane/issues/1223">issue #1223</a>) reproduces the problem not only in the GUI but also in the screenshot feature that renders the screen to an image. The backtrace from the debug build reproduced on a Linux aarch64 Docker development environment with Xvfb showed that Boa’s garbage collector halted while traversing references to an object.</p> <p>The fix in <a href="https://github.com/ieee0824/omoikane/pull/1260">PR #1260</a> (<a href="https://github.com/ieee0824/omoikane/pull/1260">PR #1260</a>) addressed the combination of an ephemeron—a conditional reference—and the generational garbage collector. A young object that was referenced by an older object was being reclaimed during the minor GC that followed a major GC. Subsequently, the major GC followed a reference that had already been freed, causing a crash.</p>https://blog.ast.moe/en/blog/2026-10-08/Thu, 08 Oct 2026 21:50:47 +0900https://blog.ast.moe/en/blog/2026-10-08/<p>JavaScript has <code>Map</code>, which stores key‑value pairs, and a similarly named <code>WeakMap</code>. Both can be registered with <code>set()</code> and retrieved with <code>get()</code>. However, WeakMap does not have <code>size</code> nor <code>keys()</code>.</p> <p>A WeakMap is a mechanism that associates information with objects without keeping the objects in memory solely because of that association. The term “weak” refers not to the data’s reliability or the accuracy of lookups, but to how the references to the keys are treated.</p>https://blog.ast.moe/en/blog/2026-09-30/Wed, 30 Sep 2026 08:12:00 +0900https://blog.ast.moe/en/blog/2026-09-30/<p>When running the test for a custom element associated with a form in Omoikane’s Web Platform Tests (WPT), it caused a SIGSEGV. The first occurrence was in a configuration that included the JIT, so we initially suspected an interaction between Boa’s JIT or its garbage collector. However, even when the JIT was disabled, the same crash could be reproduced (<a href="https://github.com/ieee0824/omoikane/issues/858#issuecomment-5890658215">issue #858</a>), and ultimately the problem lay in a tiny interval between when the getter’s returned object was produced and when it was stored in the VM’s registers.</p>https://blog.ast.moe/en/blog/2026-09-25/Fri, 25 Sep 2026 08:46:00 +0900https://blog.ast.moe/en/blog/2026-09-25/<p>While running Omoikane’s Acid3 test, the process hit a SIGSEGV under the baseline JIT configuration on macOS ARM64. I briefly mentioned this in the earlier blog post about Omoikane updates, but the cause wasn’t the test itself nor the JIT’s machine‑code generation; it lay in the Boa code we’re incorporating, specifically in the <code>Array.from()</code> section. Omoikane incorporates Boa’s source code together with the browser‑side implementation, so the fix was also applied to the engine that pulls in that code. (<a href="https://blog.ast.moe/en/blog/2026-09-20/">source</a>)</p>https://blog.ast.moe/en/blog/2026-09-13/Sun, 13 Sep 2026 20:20:51 +0900https://blog.ast.moe/en/blog/2026-09-13/<p>While working on implementing CSS in my own browser, Omoikane (<a href="https://github.com/ieee0824/omoikane">source</a>), Acid3 began crashing due to memory errors.</p> <p>The problem only occurs when the baseline JIT is enabled; it runs fine with the interpreter.</p> <p>Furthermore, Omoikane’s Acid3 runner has two execution modes, Faithful and DirectDrive. Faithful completes all 100 points, but then it crashes during DirectDrive.</p> <p>The failure manifests differently depending on the environment.</p> <table> <thead> <tr> <th>Environment</th> <th>Observed failure</th> </tr> </thead> <tbody> <tr> <td>x86_64 Linux</td> <td>SIGSEGV</td> </tr> <tr> <td>ARM64 Linux</td> <td>SIGABRT, ~60 GB allocation, SIGSEGV on rerun</td> </tr> <tr> <td>ARM64 macOS</td> <td>SIGSEGV, SIGBUS on rerun</td> </tr> </tbody> </table> <p>Even though it’s the same test, the signals differ.</p>