Concurrent GC (for Windows)

[Rainer Schuetze via Digitalmars-d]

On 13.06.2014 12:08, Dmitry Olshansky wrote:
> 13-Jun-2014 12:22, Rainer Schuetze пишет:
>>
>>>> If I add the actual copy into heap2 (i.e. every fourth page of 512
>>>> MB is
>>>> copied), I get 80-90 ms more.
>>>
>>> Aye... this is a lot. Also for me it turns out that unmapping CoW view
>>> at the last step takes the most of time.
>>
>> Maybe the memory needs to be actually flushed to the file if no mapping
>> exists. If that is the case, we could avoid that if we create another
>> temporary mapping.
>
> I thought that's what I do by keeping original view mapped.
> The time taken is ~ proportional to the number of pages modified in the
> CoW view, since these are private copies I think it might take this much
> to recycle them. It's ~1 ms if no changes are made.
>

I added COW to the concurrent GC ( 
https://github.com/rainers/druntime/tree/concurrent_gc2 ) and it seems 
more stable with respect to pause times than the version with reading 
write watches.

I also see considerable time spent during unmapping the CoW view, about 
as much as copying the data.

One issue with calling OS functions while the world is stopped: if these 
function require a lock on some synchronization object, and this object 
is locked by another thread that is suspended, we create a dead lock.

Do you know if MapViewOfFileEx and UnmapViewOfFile are lock free?

The same can happen with GetWriteWatch and ResetWriteWatch, though.