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.
