Incremental garbage collection
Ola Fosheim Grøstad
ola.fosheim.grostad at gmail.com
Fri Jan 21 18:53:03 UTC 2022
On Friday, 21 January 2022 at 13:00:31 UTC, Guillaume Piolat
> On Friday, 21 January 2022 at 11:27:51 UTC, Ola Fosheim Grøstad
>> 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
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
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?
More information about the Digitalmars-d