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

[Andrew Haley]

On 09/09/2015 01:58 PM, David M. Lloyd wrote:
> 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.

The release of the address space is a requirement.

>> 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

No, that's wrong.  We can't release the buffer until we clear the
references which point to it.  Then thread 1 has no way to reach it.

> 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.

That's already done: we can't unmap the mapping until the next safepoint.

Andrew.