MemoryMappedView.CreateView - better error message for insufficient virtual memory

[dchennells]

The static factory method of the internal MemoryMappedView is typically called from MemoryMappedFile.CreateViewAccessor(...) after a user has created a MemoryMappedFile. An overload of CreateViewAccessor() with no parameters is provided for the common case that the view is to cover the entire file. That overload results in a DefaultSize value of zero being passed to the size parameter of MemoryMappedView.CreateView().

Line 38 of the file MemoryMappedView.Windows.cs calls a check, preceded by a comment:

            // if request is >= than total virtual, then MapViewOfFile will fail with meaningless error message 
            // "the parameter is incorrect"; this provides better error message in advance
            Interop.CheckForAvailableVirtualMemory(nativeSize);

The problem is that "nativeSize" as implemented is zero under the (most?) common case just mentioned, such that the check (in Interop.Windows.cs) is not very probative:

        if (nativeSize >= totalVirtual)
        {
            throw new IOException(SR.IO_NotEnoughMemory);
        }

Now the one caller (MemoryMappedFile) of MemoryMappedView.CreateView() has the actual file length (from its FileStream, or from a native call). On line 152 of MemoryMappedFile it ensures that the filestream.length is meaningful under the default capacity/size scenario, so it could readily provide it to MemoryMappedView.CreateView() to enable an accurate lower-bound expected memory consumption calculation and check before the Pinvoke call to MapViewOfFile. (By considering both the system page size as well as the allocation granularity it is straightforward to calculate a value that matches the viewInfo.RegionSize that is later returned by the existing VirtualQuery call.)

Given that this problem is not resulting in a catastrophic failure (only a "meaningless error message," per the comment in the code) and that it may not be all that common to be mapping views of large files exceeding the available virtual memory, I'm unsure where this fits in the grand scheme of priorities. However, I wanted to log it given that I found myself adding a remedy today in my own specialized implementation in case someone eventually logs a bug on this. I'm new here, almost a first time participant, so please let me know to what extent this falls below (or above) the current level of relevance/urgency.