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

[David M. Lloyd]

On 09/09/2015 07:49 AM, Andrew Haley wrote:
> On 09/09/2015 01:41 PM, David M. Lloyd wrote:
>> If the answer to both of these can be shown to be affirmative, then I
>> think there is a real viable solution which allows immediate release of
>> backing resources, with the address space being reclaimed by GC.
>
> GC delays can be days if an object is in the old generation, and the
> Lucene people say this is a real problem for them.  I don't understand
> why you want a solution which does not meet one of the requirements.

It's a real problem for them (as stated) when the GC delay prevents 
release of the backing resources.  With my proposal it would not!  It 
would only prevent release of the address space.

> GC is great for managing heap.  For everything else it's not a
> solution.

Yet it's the only effective way to ensure that the address space is 
unused before releasing it.

The problem with an indirection approach is that it is inherently racy:

Thread 1: read indirection field
Thread 2: clear indirection field
Thread 2: release buffer
Thread 2: create new buffer with same address
Thread 1: access different buffer than expected

Even with the guard page it fails:

Thread 1: access guard page
Thread 2: protect guard page
Thread 2: release buffer
Thread 2: create new buffer with same address
Thread 1: access different buffer than expected

This is identical to the file descriptor problem:

Thread 1: read file descriptor #
Thread 2: close file
Thread 2: open new file
Thread 1: perform syscall against wrong file

You have to find a way to reserve the resource until we can be certain 
that not only is it not reachable, but also no threads have cached a 
reference to it.  For file descriptors, dup2 is used to clone a "dead" 
FD into the original number, until GC can come around and close it.

You can use a dedicated object (e.g. FileDescriptor) to make GC happen 
as quickly as it can (by nulling the sole reference and making it 
unreachable), but unless you start hooking into GC itself I don't see 
how you can ensure that something is not cached in a thread (that's what 
GC *does*).
-- 
- DML