On the D Blog--Symphony of Destruction: Structs, Classes, and the GC

[Steven Schveighoffer]

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