In certain cases, it might be be advantageous to ensure a destructor runs in the same thread as the allocation. For example, if the destructor uses TLS.
The idea I have is:
1. Add a new GC bit for "dtor locked to thread" for blocks with a destructor.
2. Preallocate enough memory to allow management of the blocks (i.e. linked list pointer, owning thread id)
3. When a block is detected as garbage, instead of finalizing/freeing the block, add it as a block to destroy inside the thread (using linked list).
4. Upon the next GC call inside the thread (or upon upon destruction), whenever the GC lock is taken, see if there are any local blocks to destroy, and destroy them, then free the blocks.
The cost would be another bitset per pool, and extra space to manage the blocks. The allocations need to be done via a new API, since the bit would assume the block is properly instrumented. How that API looks is up for discussion.
Comment #1 by robert.schadek — 2024-12-07T13:42:35Z