Added Finalizer to MemoryMappedFile

[kevmal]

Memory mapped files were not getting closed. TcImports attaches a dispose function to it's list of disposables to close the map, however, TcImports is never disposed in the "main" fsc.fs functions. So either TcImports needs to be disposed, a Finalizer needs to be added to TcImports or a Finalizer needs to be added to MemoryMappedFile. Here the Finalizer was added as close to the resources as possible.

[kevmal]

Code to demonstrate the leak. If compiled as 32-bit it will quickly run out of address space and throw an out of memory exception.

open Microsoft.FSharp.Compiler.SimpleSourceCodeServices
open System.IO

let run() =
    let scs = SimpleSourceCodeServices()

    let fn = Path.GetTempFileName()
    let fn2 = Path.ChangeExtension(fn, ".fs")
    let fn3 = Path.ChangeExtension(fn, ".dll")

    File.WriteAllText(fn2, """
    module M

    type C() = 
       member x.P = 1

    let x = 3 + 4
    """)

    let errors1, exitCode1 = scs.Compile([| "fsc.exe"; "-o"; fn3; "-a"; fn2 |])
    ()

for i = 1 to 200 do
    run()

[quasilord]

@kevmal We tried to reproduce this on Windows but it didn't run out of memory using the example above. What operating system were you using?

[quasilord]

(Regardless we will switch away from using memory mapped files for the SimpleSourceCodeServices compilation methods, they just read in-memory)

[kevmal]

@quasilord Windows 8, Windows Server 2012 and I just ran it on Windows 7 64-bit targeting .NET 4.5 32-bit using nuget to get FSharp.Compiler.Service. It's important it's compiled to 32-bit since it actually just seems to run out of address space to map files to. Watching the "Working Set (Memory)" in task manager it throws the exception when the working set hits about 500MB, which on this machine takes roughly 60 seconds. When not targeting 32-bit I've seen the working set memory just continue 11GB+ with no exception thrown.

[quasilord]

Thank you, I was looking at "Memory (Private working set)"

[quasilord]

FCS 0.0.45 now opens binaries in-memory instead of using memory mapped files.

Thanks for raising this issue, closing this since the visible issue has been addressed.

Note this is still a good PR for basic code quality improvement but it would really belong in the core F# implementation from which this repo is derived (see http://github.com/fsharp/fsharp and http://visualfsharp.codeplex.com). So we shouldn't accept it here unless it is fixing an active FCS bug.