Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

David M. Lloyd david.lloyd at
Tue Sep 8 17:54:42 UTC 2015

On 09/08/2015 12:40 PM, Andrew Haley wrote:
> On 09/08/2015 06:03 PM, David M. Lloyd wrote:
>> On 09/08/2015 08:11 AM, Andrew Haley wrote:
>>> On 09/08/2015 12:37 PM, David M. Lloyd wrote:
>>>> Then you do the real unmap when
>>>> the buffer is GC'd (maybe via Cleaner).  This is very akin to how file
>>>> descriptors are cleaned up, AFAICT.
>>> Indeed it is, and it's no better than the status quo.  This is an attempt
>>> to do better.
>> Actually it *is* better, as it releases the mapping to the underlying
>> file, and does not require any resources (outside of the page table
>> itself and any associated kernel bookkeeping) to maintain a valid state
>> during the time window between user-driven unmap and automatic GC.  The
>> underlying file can (for example) immediately relinquish reserved disk
>> storage or RAM at unmap time (the desired effect), rather than waiting
>> for GC to come around (status quo).
>> I believe that reclaiming the reserved address space is of much less
>> importance than freeing the backing resources (especially for 64-bit
>> systems), which is why I suggest this approach.
> I think you may be assuming rather a lot about the way that the
> underlying OS actually works.  The bug report mentions race conditions
> when remapping, and not every OS has nice UNIXy semantics.  Hence my
> proposal, which might be portable to other OSs.

It's at least been in POSIX since 2008: "This volume of POSIX.1‐2008 
specifies that [..] new [MAP_FIXED] mappings replace any existing 
mappings, following existing practice in this regard."  Linux agrees: 
"If the memory region specified by addr and len overlaps pages of any 
existing mapping(s), then the overlapped part of the existing mapping(s) 
will be discarded."  BSD seems to agree as well, as does Solaris, and I 
can't seem to find any public reference to known race conditions with 
this kind of operation.

I think the only questionable platform at this point is Windows (to me 
at least, given that I do not have much experience on it).

More information about the core-libs-dev mailing list