Incremental garbage collection

[Ola Fosheim Grøstad]

On Friday, 21 January 2022 at 13:00:31 UTC, Guillaume Piolat 
wrote:
> 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.

Yes, for a plugin that is reasonable. I think an audio-friendly 
garbage collector would be more for a language-like application 
like Max, or maybe even a complex sound editor.

But even if you do make your realtime tasks independent of the 
GC, it is still better to have a collector that is throttling the 
collection in the background so it doesn't wipe out the caches or 
saturate the data bus. Then you get more headroom for your 
realtime tasks (you get a more even load over 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.

Hm, how would you use amortized algorithms in a real time thread 
where you want even load on every callback? I guess you could use 
"coroutines" and spread the load over many 
"interrupts"/"callbacks".

One strategy for dynamic allocation is to have "chunks" for same 
sized allocations (avoiding fragmentation and merging), and then 
do a worst case estimate for how many allocations can happen in 
one realtime-callback. Then a non-realtime thread can make sure 
that there is enough free space in the chunks to support N 
callbacks.

Another strategy I have used that may be used if you do not write 
a plugin, but create your own host, is to pass in the buffers 
needed in the events you send to the realtime thread. Then have a 
mailbox for returning the buffers and let a non-realtime thread 
do the cleanup.

> 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.

Is that a dedicated GC for wren or is it a generic GC?