Avoid repeated pointer-array shifts when releasing GC block groups #207

releaseEmptyGroups in src/hx/gc/Immix.cpp removes each released block with mAllBlocks.erase(i). QuickVec::erase shifts the remaining suffix with memmove. Releasing many blocks in one collection can therefore repeatedly move the same surviving metadata and perform quadratic pointer-copy work while mutators are stopped.

The order matters because mAllBlocks is used for address-ordered block lookup, so replacing erase with an unordered removal is not sufficient.

A metadata-only probe against checkout 03a4e8d on Linux x86_64 through WSL used the actual hx::QuickVec<void*>::erase implementation, removing all entries from the front of a populated array. Built with g++ -O2 -std=c++17:

This reproduces the removal pattern and isolates its metadata cost. It does not create or free a real GC heap and is not an end-to-end collection benchmark. In the actual collector, the cost depends on which positions are released and how many blocks survive. At the default 32 KiB block size, 65536 blocks describe 2 GiB of block storage.

Consider destroying released BlockDataInfo objects while compacting surviving pointers with one stable forward pass, then reducing the vector size once. Preserve sorted order and the existing updates to emptyBlocks, gBlockInfo slots and group ownership. Do not leave released pointers in the live prefix.

Measure real burst-then-compact workloads, partial group release and repeated grow/shrink cycles. Record the metadata cleanup phase separately from OS deallocation and moving/marking work. Require default, big-block, moving, generational and verifier checks. Related: #69 introduced non-moving group release, and #151 provides performance coverage.