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

[Peter Levart]

On 09/08/2015 09:15 PM, Remi Forax wrote:
> On 09/08/2015 03:29 PM, Andrew Haley wrote:
>> On 09/08/2015 02:05 PM, Andrew Haley wrote:
>>> I don't think you'd actually need to unmap anything until a safepoint.
>>> I don't think that the speed of unmapping is critical as long as it
>>> happens "soon".
>> Although given the desire to do
>>
>>    buffer.unmap();
>>    file.delete();
>>
>> that belief may be misplaced.  We could just block for a safepoint;
>> we already do that in other cases, and there's no guarantee about how
>> long unmap() would take to execute.
>>
>> Andrew.
>>
> I think a simple way to solve that is to ask for a safepoint explicitly,
>
>    buffer.unmap();
>    waitUntilUnmapped();
>    file.delete();
>
> Rémi

Hi,

The following can already be performed today:

buffer = null;
waitUntilUnmapped();
file.delete();


The tricky part is how to do waitUntilUnmapped() and maybe even help 
ReferenceHandler thread and/or trigger reference processing while 
waiting. Here's an example that executes an asynchronous callback after 
the memory has been unmapped:

http://cr.openjdk.java.net/~plevart/jdk9-dev/4724038_MappedByteBuffer_afterRelease/webrev.01/

The test shows how one could delete the file after it has been unmapped 
(if the byte buffer was the only mapping).

Would such notification be enough to cover the use cases? What are the 
use cases one would like to cover with hypothetical unmap() was it 
available?


Regards, Peter

> ----- Mail original -----
>> De: "Andrew Haley" <aph at redhat.com>
>> À: core-libs-dev at openjdk.java.net
>> Envoyé: Mardi 8 Septembre 2015 15:29:25
>> Objet: Re: Suggested fix for JDK-4724038 (Add unmap method to	MappedByteBuffer)
>>
>> On 09/08/2015 02:05 PM, Andrew Haley wrote:
>>> I don't think you'd actually need to unmap anything until a safepoint.
>>> I don't think that the speed of unmapping is critical as long as it
>>> happens "soon".
>> Although given the desire to do
>>
>>    buffer.unmap();
>>    file.delete();
>>
>> that belief may be misplaced.  We could just block for a safepoint;
>> we already do that in other cases, and there's no guarantee about how
>> long unmap() would take to execute.
>>
>> Andrew.
>>
>>