• d-bugmail puremagic.com (30/30) Apr 06 2023 https://issues.dlang.org/show_bug.cgi?id=23831

d-bugmail puremagic.com writes:

https://issues.dlang.org/show_bug.cgi?id=23831

          Issue ID: 23831
           Summary: [GC] support option to always run dtor in allocating
                    thread
           Product: D
           Version: D2
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: druntime
          Assignee: nobody puremagic.com
          Reporter: schveiguy gmail.com

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.

--