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

[Andrew Haley]

On 09/10/2015 02:48 PM, David M. Lloyd wrote:
> On 09/10/2015 08:22 AM, Andrew Haley wrote:
>> On 09/10/2015 12:25 PM, Vitaly Davidovich wrote:
>>
>>> The safepoint happiness is unfortunately a separate issue in
>>> Hotspot, and it's definitely not happy times :).  Part of the
>>> problem is the piggybacking of various operations on a safepoint -
>>> the safepoint time alone (not counting GC, say) keeps growing.  You
>>> probably could piggyback this on GuaranteedSafepointInterval
>>> safepoints, but those are currently predicated on IC buffers needing
>>> to be cleaned.
>>
>> OK.  I see that there is a conflict here.
> 
> Is it possible that the operation could be simplified - down to setting 
> a flag maybe - so that the expensive/potentially dangerous stuff (the 
> actual unmap) can be done in a proper thread?

Sure.

The mapping can't be removed until you know for sure that no thread is
using it.  For that to be known you need a safepoint, but (you may
like this) the safepoint itself doesn't have to actually do anything.
I imagine it would go like this:

write-protect the guard page
trigger a safepoint ...
... wait for safepoint to complete
remove the mapping

>>> Would we exceed the complexity budget if posix systems would use
>>> memory remapping and windows safepoints?
>>
>> I can still see address space exhaustion happening on unices.
> 
> Still, it's important to remember that the status quo currently
> exhausts address space *and* actual backing resources, so anything
> is really an improvement at this point...

Yea, but much of the effort of developing something like this is the
overhead of discussions, creating bugs, and so on.  Once the box is
opened the extra effort of doing it properly is relatively cheap.  And
besides, where is the pleasure in writing a half-arsed solution?

Andrew.