Concurrent GC (for Windows)

[Dmitry Olshansky via Digitalmars-d]

14-Jun-2014 20:34, Rainer Schuetze пишет:
>
>
> 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.
>

How do I run benchmarks and what are the newest results for you?

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

No idea. It may also depend on OS version, given the fuzz about Win7 
being the first with lock-free thread scheduler there may be giant-locks 
in memory-mapping at least in some versions.

>
> The same can happen with GetWriteWatch and ResetWriteWatch, though.


-- 
Dmitry Olshansky