6816049: (bf) MappedByteBuffer.force() method does not flush data correctly

[Alan Bateman]

MappedByteBuffer.force doesn't currently work as expected on Windows 
because that operating system doesn't provider the equivalent of msync 
with MS_SYNC semantics. It's currently implemented with FlushViewOfFile 
but that is essentially msync(MS_ASYNC) and so doesn't wait until the 
dirty pages have been written to the disk. We've been back and forth 
with Microsoft on this a few times with a view to encouraging them to 
add support in a future release. In the mean-time, the only way to 
address this is to keep a handle to the original file and use 
FlushFileBuffers. This isn't completely satisfactory but preferable to 
having force complete prematurely.

To keep things simple, the changes here duplicate the file handle when 
creating a file mapping so that it may be used subsequently by the force 
method. In other words, on Windows, each mapped buffer will have its own 
handle to the original file. This allows the file channel to be "closed" 
after the mapping is obtained, although the underlying file will remain 
open until the channel, and all mapped buffers obtained from it, are 
closed. The solution is preferable to changing the close mechanism and 
keeping track of each of the mapped buffers. The side effects to keeping 
the file open aren't as bad as it might appear and the only real issue 
that I can think of is where someone continues to use the channel after 
mapping a region, some I/O operation on the file blocks because of a 
network/other issue, and the asynchronous close doesn't preempt it. On 
balance it's probably not worth worrying about this case as the I/O 
operation will complete in a timely manner with the error anyway.

The webrev with the changes is here:
  http://cr.openjdk.java.net/~alanb/6816049/webrev/

Thanks,
-Alan.