Incremental garbage collection
Ola Fosheim Grøstad
ola.fosheim.grostad at gmail.com
Sat Jan 22 13:03:26 UTC 2022
On Friday, 21 January 2022 at 20:17:16 UTC, Guillaume Piolat
wrote:
> On Friday, 21 January 2022 at 18:53:03 UTC, Ola Fosheim Grøstad
> wrote:
>>
>> Is that a dedicated GC for wren or is it a generic GC?
>
> Wren use its own non-moving, non-incremental, precise,
> stop-the-world mark&sweep GC.
But it only stops the wren-code, so it does not affect real time
properties of the main program? I think this is the better
approach for system level programming. Have dedicated memory
management where you get to control the properties and
priorities, and also have the ability to add new mechanisms (like
purging cached objects).
IIRC, the author of the audio-oriented GC suggested implementing
the collector as a coroutine, so that you could execute it when
the CPU is idle in a controlled manner.
Many ways to be inventive here, if you focus on adapting to the
specifics of the application. There is no-size-fits-all solution.
So, the main issue is not GV vs no-GC, but whether the
language/libraries lock you to the specifics of a generic runtime.
More information about the Digitalmars-d
mailing list