Incremental garbage collection

Guillaume Piolat first.last at gmail.com
Fri Jan 21 13:00:31 UTC 2022


On Friday, 21 January 2022 at 11:27:51 UTC, Ola Fosheim Grøstad 
wrote:
>
> Makes sense to me for that particular niche. Might also work 
> for embedded with the caveat that you need extra memory.

While it must be interesting, another solution you have in D is 
to deregister audio threads so that a GC pause would let them run 
free. The audio threads rarely owns GC root anyway.

Despite popular conception, it's indeed common to allocate from 
the audio-thread at first buffer, it can avoid some pessimization 
depending on incoming parameters that are only known at play time.

Amortized malloc is surprisingly cheap, you can merge allocation 
buffers, and you would do it only once at initialization. A lot 
of the audio buffers are also scoped in nature, with a lifetime 
that is the one of the processing treatment. So you can also 
leverage specialized allocators to mass release those buffers 
rapidly.

In Dplug plugins we got a GC back :) by integrating Wren as UI 
scripting language. It is expected to cause very few problems, as 
it has a max-heap size and doesn't touch audio.



More information about the Digitalmars-d mailing list