Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)
David M. Lloyd
david.lloyd at redhat.com
Tue Sep 8 16:58:15 UTC 2015
On 09/08/2015 08:03 AM, Mike Hearn wrote:
> If you're already doing this, why not skip the level of indirection
> and mprotect the entire mapped region to PROT_NONE when the user
> unmaps? ....... Then you do the real unmap when the buffer is GC'd
> (maybe via Cleaner).
> Because the reason users are working around this is Windows, where they
> need the ability to do:
> If the unmap is still asynchronous it doesn't solve the problem.
So Windows has no operation which can remap a previously mapped section
of memory to something else? (say, just a block of non-access memory)
Note that such an operation has to be atomic with respect to all other
operations which affect the address space of the process (or at least,
which may randomly choose an address in memory at which to create new
mappings), but not with respect to anything else really. The point of
the remapping is to continue to reserve the address space, without
actually referencing what was there before (thus dodging file lock
issues). No physical or virtual memory need actually be reserved for
such a mapping.
More information about the core-libs-dev