On reddit:

http://www.reddit.com/r/programming/comments/1eovfu/dconf_2013_day_1_talk_6_concurrent_garbage/


Enjoy! Discuss!! Vote!!!

Andrei

Andrei Alexandrescu:

> http://www.reddit.com/r/programming/comments/1eovfu/dconf_2013_day_1_talk_6_concurrent_garbage/

This link on the YouTube page seems to not be online:

http://dconf.org/2013/talks/lucarella.pdf

Bye,
bearophile

On Mon, 20 May 2013 13:50:25 +0100, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On reddit:
> http://www.reddit.com/r/programming/comments/1eovfu/dconf_2013_day_1_talk_6_concurrent_garbage/

This may be the Windows Copy On Write feature mentioned in the Q&A at the end:
http://support.microsoft.com/kb/103858

.. but it's not clear to me how useful this is for fork emulation or similar.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Mon, 20 May 2013 08:50:25 -0400
Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On reddit:
> 
> http://www.reddit.com/r/programming/comments/1eovfu/dconf_2013_day_1_talk_6_concurrent_garbage/
> 

Torrents up, as well as links:

http://semitwist.com/download/misc/dconf2013/

On Monday, 20 May 2013 at 13:55:05 UTC, Regan Heath wrote:
> On Mon, 20 May 2013 13:50:25 +0100, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On reddit:
>> http://www.reddit.com/r/programming/comments/1eovfu/dconf_2013_day_1_talk_6_concurrent_garbage/
>
> This may be the Windows Copy On Write feature mentioned in the Q&A at the end:
> http://support.microsoft.com/kb/103858
>
> .. but it's not clear to me how useful this is for fork emulation or similar.
>
> R

Fork isn't needed at all really in the technique described, this is all that's needed:
- Map a copy of the memory using copy-on-write
- Run some code concurrently

It just happens that fork does both of these things, but you can equally well do the two things using separate calls.

In fact you should be able to avoid the deadlock issue by not using fork but just remapping some shared memory using copy on write. The GC can exist in a separate thread which pauses itself after every run. To run the GC it's then just a case of:
- stop the world
- copy registers to stack
- remap shared memory using COW
- resume the world
- resume the GC thread

And that would work on all modern OSes, plus you don't have the overhead of creating a new process or even a new thread. Also immutable memory doesn't need to be mapped, the GC thread can access it directly.

On Monday, 20 May 2013 at 22:52:33 UTC, Diggory wrote:
> And that would work on all modern OSes, plus you don't have the overhead of creating a new process or even a new thread. Also immutable memory doesn't need to be mapped, the GC thread can access it directly.

Copy on WRITE usually don't happen on immutable memory.

On Tuesday, 21 May 2013 at 00:00:13 UTC, deadalnix wrote:
> On Monday, 20 May 2013 at 22:52:33 UTC, Diggory wrote:
>> And that would work on all modern OSes, plus you don't have the overhead of creating a new process or even a new thread. Also immutable memory doesn't need to be mapped, the GC thread can access it directly.
>
> Copy on WRITE usually don't happen on immutable memory.

I never said it did... I said that when using fork the immutable memory must be mapped into the new process, when using a thread it does not since threads share the same address space.

On Monday, 20 May 2013 at 13:55:05 UTC, Regan Heath wrote:
> On Mon, 20 May 2013 13:50:25 +0100, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On reddit:
>> http://www.reddit.com/r/programming/comments/1eovfu/dconf_2013_day_1_talk_6_concurrent_garbage/
>
> This may be the Windows Copy On Write feature mentioned in the Q&A at the end:
> http://support.microsoft.com/kb/103858

Yes, basically. I can't find where I've read that mapping COW memory from within the same process is only supported on NT versions. However, doing it from within the same process is not practical anyway, since that would imply at least halving the address space.

On Tuesday, 21 May 2013 at 04:26:18 UTC, Vladimir Panteleev wrote:
> On Monday, 20 May 2013 at 13:55:05 UTC, Regan Heath wrote:
>> On Mon, 20 May 2013 13:50:25 +0100, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>
>>> On reddit:
>>> http://www.reddit.com/r/programming/comments/1eovfu/dconf_2013_day_1_talk_6_concurrent_garbage/
>>
>> This may be the Windows Copy On Write feature mentioned in the Q&A at the end:
>> http://support.microsoft.com/kb/103858
>
> Yes, basically. I can't find where I've read that mapping COW memory from within the same process is only supported on NT versions. However, doing it from within the same process is not practical anyway, since that would imply at least halving the address space.

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.

On 64-bit systems there shouldn't be a problem with address space, and even on 32-bit systems, the objects which take up the vast majority of the address space are usually arrays of primitive types which don't need to be scanned by the GC.

Certainly for 64-bit systems I think it's worth at least doing some performance comparisons, and I think using a thread will turn out to be more efficient. If it turns out that there are merits to both options then having a GC option to use a process or a thread might make sense.

On 2013-05-20 14:50, Andrei Alexandrescu wrote:
> On reddit:
>
> http://www.reddit.com/r/programming/comments/1eovfu/dconf_2013_day_1_talk_6_concurrent_garbage/

Great talk. What's up with the extra minute added in the beginning?

-- 
/Jacob Carlborg