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
