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

[Vladimir Panteleev]

On Friday, 24 May 2013 at 09:56:25 UTC, Diggory wrote:
> I'm fairly sure windows only shares memory between instances of 
> the same DLL, not executables.

Oh? I thought Windows treats all modules in the same way. Do you 
have a source?

> 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 see that as a problem, considering such a GC would need 
to be opt-in.

> 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.

The reason why I asked for a specific example is that I don't 
know of any actual case when this will be a problem in practice.

For one, I've never seen security software that reacts 
differently on two instances of the same executable - usually, 
any permissions you set are for the .exe file, or more generic 
rules (like port numbers).

For two, the satellite process does not need any kinds of 
permissions. Even the requirement of accessing other processes' 
memory that the straight-forward approach needs can be avoided by 
allowing the satellite process to inherit a handle to the main 
process.

> 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.

Yes, which is why I also think it should be opt-in.

>> 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.

Leandro wasn't using Windows ;)