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
