Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)
Andrew Haley
aph at redhat.com
Wed Sep 9 13:06:40 UTC 2015
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.
More information about the core-libs-dev
mailing list