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