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

[Chris Hegarty]

Looks fine, some minor comments:

The Direct-X-Buffer constructors, not for memory-mapped buffers, can 
simply invoke 4 arg super constructor, instead of passing a null fd, 
right? Thought, this was always the case.

The indentation of L55 (2nd line of args to force0) of the windows 
version of MappedByteBuffer.c seems wrong (too much). Or maybe this is 
webrev.

-Chris.

Alan Bateman wrote:
> 
> 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.