nhz2
June 15, 2025, 7:25pm
1
Currently the Mmap.mmap function uses a finalizer to handle calling munmap or UnmapViewOfFile when the array is garbage collected.
It is useful to be able to do this finalization eagerly despite the potential risks if there are any unexpected references. Ref:
I think the `ref` field is not public.
I’m struggling to get ZipArchives.jl and Mmap.jl to work together in the way I want - basically just following the docs.
MWE looks like this:
using ZipArchives
using Mmap
io=open("simpletest.zip")
mm=Mmap.mmap(io)
q = ZipArchives.ZipReader(mm)
readme_n_lines = zip_openentry(q, "xl/worksheets/sheet1.xml") do z
countlines(z)
end
close(io)
#GC.gc()
ZipArchives.ZipWriter("simpletest.zip") do w
zip_newfile(w, "test/test2.txt")
write(w, "I am data inside test2.txt in the zip file")
end…
master ← kc/finalizer_mmap
This broke TextParse.jl (and I believe CSV.jl also). Both used calls to `finaliz… e(array)` to deterministically release the OS resources associated with memory mapped files. Both now have workarounds, but they feel hacky as they are now depending on what is presumably internals (see e.g. https://github.com/JuliaData/CSV.jl/blob/9f95cfbd82fd0096497a26eb57998ec66758bcb6/src/file.jl#L342-L347).
Currently CSV.jl uses does the following as a workaround:
Could a function that does this be added to the Mmap API as @topolarity suggested in attach finalizer in `mmap` to the correct object by KristofferC · Pull Request #54210 · JuliaLang/julia · GitHub
1 Like
TimG
June 16, 2025, 7:41am
2
We already know that a well placed GC call can have the desired effect. The downside is that garbage collection is expensive and probably does (much) more than is necessary for mmap alone. So my naive view is that it should be possible to isolate that bit of the GC call that does the trick for mmap and implement that as part of the mmap API.
1 Like