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.lev...@gmail.com> > À: "Remi Forax" <fo...@univ-mlv.fr>, "Andrew Haley" <a...@redhat.com> > Cc: core-libs-dev@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" <a...@redhat.com> À: core-libs-dev@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. > > >
