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

David M. Lloyd david.lloyd at redhat.com
Wed Sep 9 13:13:43 UTC 2015


On 09/09/2015 08:06 AM, Andrew Haley wrote:
> 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.

How would you hook into the safepoint to perform the unmapping?  You'd 
have to wait for all threads to arrive at safepoints, wouldn't you?

-- 
- DML



More information about the core-libs-dev mailing list