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