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

[forax at univ-mlv.fr]

Hi Peter, 
the problem of your approach is that you rely on the GC and as the others have said, 
usually a MappedByteBuffer is used a long time so it goes to a region that is not clean frequently by the GC (if cleaned at all) 
so it requires a FullGC, and there is no real way to ask for a FullGC in Java. 

so either as Andew has suggested, unmap asks the VM to go to a safepoint or 
unmap is asynchronous and ask the VM to do the unmapping/page protect trick at the next safepoint and we need a special call to be able 
to wait for the ummaping to happen in the thread that want to do a file.delete(). 

Rémi 

----- Mail original -----

> De: "Peter Levart" <peter.levart at gmail.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "Andrew Haley" <aph at redhat.com>
> Cc: core-libs-dev at openjdk.java.net
> Envoyé: Mercredi 9 Septembre 2015 00:37:13
> Objet: Re: Suggested fix for JDK-4724038 (Add unmap method to
> MappedByteBuffer)

> 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.
> > 
>