C
Claire Chan
Hi,
I'm learning about using MappedByteBuffer in java.nio to read and write
large memory-mapped files. I was surprised I couldn't find the munmap
functionality and that the documentation suggests mapping files should
only be used for large long-living objects. It wasn't clear under what
circumstances, the memory region becomes unmapped.
I double-checked the linux mmap system call man pages, which said that
closing the file descriptor does not munmap. I also tried looking in the
java source to see what happens there and did some experimentation. It
looks like creating MappedByteBuffers causes threads to be spawned to do
the cleanup via munmap at gc time. I was trying to figure out exactly
when the unmapping takes place to make sure that despite the
recommendation to use MappedByteBuffer only for long lived objects, my
intended use of it for short-lived objects will also work ok. It looks
fine running the tests with my application where MappedByteBuffers are
continually created and destroyed, but I'd like to get some
confirmation. Can somebody tell me if I understood this correctly?
It seems when DirectByteBuffers are first created by mapping (not by
taking duplicates or slices), they are associated with a runnable
sun.misc.Cleaner object which will run when this original
DirectByteBuffer object is collected. The views obtained by duplicates
and slices hang on to a reference of the original so that it is safe
that unmapping will not take place until all views of the original dbb
are unreachable, and unmapping will only take place once for all views.
I take it that the reason munmap is not implemented is that it would
interfere with this automated treatment. And for the same reason there
should never be a need for it. It would be good if someone could point
out additional sources of info on the workings of the
unmapping/cleaning... I'm reading up a bit more on java.lang.ref.* right
now.
Thanks a lot,
Claire
I'm learning about using MappedByteBuffer in java.nio to read and write
large memory-mapped files. I was surprised I couldn't find the munmap
functionality and that the documentation suggests mapping files should
only be used for large long-living objects. It wasn't clear under what
circumstances, the memory region becomes unmapped.
I double-checked the linux mmap system call man pages, which said that
closing the file descriptor does not munmap. I also tried looking in the
java source to see what happens there and did some experimentation. It
looks like creating MappedByteBuffers causes threads to be spawned to do
the cleanup via munmap at gc time. I was trying to figure out exactly
when the unmapping takes place to make sure that despite the
recommendation to use MappedByteBuffer only for long lived objects, my
intended use of it for short-lived objects will also work ok. It looks
fine running the tests with my application where MappedByteBuffers are
continually created and destroyed, but I'd like to get some
confirmation. Can somebody tell me if I understood this correctly?
It seems when DirectByteBuffers are first created by mapping (not by
taking duplicates or slices), they are associated with a runnable
sun.misc.Cleaner object which will run when this original
DirectByteBuffer object is collected. The views obtained by duplicates
and slices hang on to a reference of the original so that it is safe
that unmapping will not take place until all views of the original dbb
are unreachable, and unmapping will only take place once for all views.
I take it that the reason munmap is not implemented is that it would
interfere with this automated treatment. And for the same reason there
should never be a need for it. It would be good if someone could point
out additional sources of info on the workings of the
unmapping/cleaning... I'm reading up a bit more on java.lang.ref.* right
now.
Thanks a lot,
Claire