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

[Diggory]

On Friday, 24 May 2013 at 07:48:49 UTC, Vladimir Panteleev wrote:
> I don't know why you say that. The satellite process would be 
> the same executable file as the main process, but started with 
> a special switch (or environment variable), which will be 
> handled by the D runtime. Since the two processes use the same 
> image, the executable code will share the same pages in memory, 
> resulting in a small overhead.

I'm fairly sure windows only shares memory between instances of 
the same DLL, not executables.

> When implementing WinMain, you have to call the runtime 
> initialization function, which will initialize the GC. GC 
> initialization for the satellite process need not exit.

You're still executing part of the user's code and it's going to 
be exceedingly hard to satisfactorily explain why the main 
function will be called twice except the second time it will 
mysteriously stop half-way through because the runtime init 
function doesn't return...

> I don't think this is true. Although the image subsystem is 
> auto-detected by the entry point you're using (CONSOLE for 
> main, WINDOWS for WinMain), you can specify it explicitly using 
> the /SUBSYSTEM linker switch (/SUBSYSTEM:WINDOWS).

The only time I've been able to get it to not show a console 
window is when using WinMain...

> Sorry? Could you provide an example (with a specific security 
> software package)?

Any security software with the active defense type stuff, Commodo 
does it for example. The things they ask you about vary and it's 
completely pointless IMO, but they do ask for permission for 
practically everything and with two processes that's twice as 
much to ask you about.

Anyway, my main point is that it's not the kind of thing you want 
to impose as standard on all D applications, there may be other 
problems it causes depending on what the program is for. If it 
exists at all it should be opt-in and the default should still be 
as performant as possible.

> I've tried writing a generational GC for D that used page 
> protection for write barriers a while ago. IIRC, I ran into 
> performance issues (the page faults were rather expensive).

Hmm, it shouldn't really be much slower than the technique 
Leandro was using - both rely on the exact same number of page 
faults - and his results looked very promising.