On 3/18/21 8:55 AM, Mike Parker wrote:
On Thursday, 18 March 2021 at 12:27:56 UTC, Petar Kirov [ZombineDev] wrote:
Just implementation deficiency. I think it is fixable with some
refactoring of the GC pipeline. One approach would be, (similar to
other language implementations - see below), that GC-allocated objects
with destructors should be placed on a queue and their destructors be
called when the GC has finished the collection. Afterwards, the GC can
release their memory during the next collection.
As I understand, finalizers in D are run because the GC needs more
memory *now*. Deferring release of memory until the next collection
would defeat the purpose. We would need to decouple collection cycles
from allocation. Am I missing something?
I think this is the proper way to look at it. We are running a
collection cycle because more memory is needed. If you allocate inside
the GC, likely you would trigger another GC.
However, there are probably ways around this. For instance, you can
allocate memory without triggering a GC, and we can probably try that
instead.
AIUI, the stop-the-world phase is only for scanning. Once scanning is
done, there is nothing to say we can't change the pool data while
looking for blocks to finalize.
Most likely, some of them will free up blocks that then can be used by a
finalizer allocation.
Would be a good SAOC project.
-Steve
