-
Enhancement
-
Resolution: Won't Fix
-
P4
-
None
-
1.4.0, 5.0, 7
FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)
FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195]
A DESCRIPTION OF THE PROBLEM :
Once a file has been mapped a number of operations on that
file will fail until the mapping has been released (e.g.
delete, truncating to a size less than the mapped area).
However the programmer can't control accurately the time at
which the unmapping takes place --- typically it depends on
the processing of finalization or a PhantomReference queue.
The danger associated with unmapping that is noted in the
JavaDoc could be avoided if when an area is unmapped, the
memory is not made available for reallocation but instead
is reserved (e.g. by using VirtualAlloc under Windows).
Then any unwanted reference to the previously mapped area
would result in an exception without incurring performance
penalties. The finalization process could release the
reservation when there were no remaining references to the
buffer.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Run the attached code.
2. A 1KB file will remain --- the File.delete call fails
unless the System.gc() is uncommented. However we can't
rely on the GC call actually doing anything.
EXPECTED VERSUS ACTUAL BEHAVIOR :
There is no way of ensuring that the delete will work even
though we are no longer interested in the mapping.
The deleteOnExit doesn't work either (with far less excuse)
and I have submitted a bug report for that.
REPRODUCIBILITY :
This bug can be reproduced often.
---------- BEGIN SOURCE ----------
import java.io.*;
import java.nio.MappedByteBuffer;
import java.nio.channels.FileChannel;
class TestMemoryMapping
{
public static void main(String[] args)
{
try
{
File f = File.createTempFile("Test", null);
f.deleteOnExit();
RandomAccessFile raf = new RandomAccessFile(f, "rw");
raf.setLength(1024);
FileChannel channel = raf.getChannel();
MappedByteBuffer buffer = channel.map
(FileChannel.MapMode.READ_WRITE, 0, 1024);
channel.close();
raf.close();
buffer = null;
// System.gc();
if (f.delete())
System.out.println("Temporary file
deleted: "+f);
else
System.out.println("Not yet deleted: "+f);
}
catch (IOException ex)
{
ex.printStackTrace();
}
}
}
---------- END SOURCE ----------
(Review ID: 153923)
======================================================================
- duplicates
-
JDK-6893654 Mapping large files leads to system "death" due to catastrophic swapping
- Closed
-
JDK-8144174 Potential off-heap memory leak, while FileChannel.map
- Closed
-
JDK-6558368 (bf) MappedByteBuffer.release()/close() to release system resources
- Closed
-
JDK-8028683 Memory-Mapped files cannot be renamed
- Closed
- relates to
-
JDK-6359560 (fs) File.deleteOnExit() doesn't work when MappedByteBuffer exists (win)
- Closed
-
JDK-6417205 (fc) Out of address space because mapped ByteBuffers are not freed
- Resolved
-
JDK-8295368 File.delete is not working as expected
- Closed
-
JDK-6296278 (bf) ByteBuffer (et al) needs a way to explicitly release the underlying buffer.
- Open
-
JDK-8310626 JEP 454: Foreign Function & Memory API
- Closed