DConf 2013 Day 1 Talk 6: Concurrent Garbage Collection for D by Leandro Lucarella

[Diggory]

On Thursday, 23 May 2013 at 12:39:04 UTC, Vladimir Panteleev 
wrote:
> On Tuesday, 21 May 2013 at 04:52:25 UTC, Diggory wrote:
>> Either way, at least on windows the separate process would 
>> have to be persistent as creating a new process has a lot more 
>> overhead attached to it than on posix systems. Implicitly 
>> creating a child process is also something a D programmer 
>> might not want, again this is more windows specific where 
>> processes do not have the same strict hierarchy as on posix.
>
> What would be some of the potential downsides of a long-running 
> satellite process?
>
> A concurrent GC would probably be opt-in or opt-out, either way.

You'd either have to distribute a separate .exe for the GC 
process or embed the second .exe inside the first and extract it 
at runtime to a temporary location, or call the same .exe with 
some flag which tells it to turn into a GC. None of those options 
are particularly nice, all of them require significant 
interference from the GC, it's not just a case of calling some 
function to start the GC. This is especially a problem in cases 
where the runtime can't insert the init handler such as when 
using WinMain, which you currently have to do unless you want a 
console window to pop up.

Next there's the fact that you have a separate top level process 
for every D process. This is going to cause problems with 
security software since you now have to give both processes 
permissions in order to run. In addition you have to consider the 
case where one or other of the two processes is paused or killed 
unexpectedly - you don't want orphaned GC processes hanging 
around wasting resources.