-
Bug
-
Resolution: Duplicate
-
P3
-
None
-
1.4.0
-
generic
-
generic
Name: gm110360 Date: 10/11/2001
I'm using the imageio.jar form 1.4beta, but with:
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)
Every time I use "ImageIO.write(img, "png", outStream)" a temporary file is
created, and the "deleteOnExit()" function is called on that temporary file.
Every "deleteOnExit()" allocates a "struct dlEntry" in the shared "io_util.c"
native source file. This "struct dlEntry" is about 1K in size, and will never be
freed until the system exits, so every time I do an ImageIO.write() I take up
another 1K of memory! This is in a JSP engine that is creating dynamic images,
so I want it to be able to run a long time, but at 1 image/minute it will
consume 1.5MB per day that the JSP engine is up. This is absurd. It seems that
no package should use "deleteOnExit()" dynamically - it guarantees a memory
leak. In a long-running system like a JSP engine, this is completely unacceptable.
It would be better if the temporary file were deleted when the image data was
garbage collected, or some such, so there was no need to allocate a struct
dlEntry in the native code.
(Review ID: 133570)
======================================================================
Its possible to solve the ImageIo problem if there is a version of
deleteOnExit that returns a unique identifier. Clients such as ImageIO
who remove the file before exit can then call an API to remove the
file referenced by that unique identifier from the internal list of
files to delete on exit.
long deleteOnExit2()
public static void removeFromDeleteList(long)
###@###.### 2003-04-02
============================
I'm using the imageio.jar form 1.4beta, but with:
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)
Every time I use "ImageIO.write(img, "png", outStream)" a temporary file is
created, and the "deleteOnExit()" function is called on that temporary file.
Every "deleteOnExit()" allocates a "struct dlEntry" in the shared "io_util.c"
native source file. This "struct dlEntry" is about 1K in size, and will never be
freed until the system exits, so every time I do an ImageIO.write() I take up
another 1K of memory! This is in a JSP engine that is creating dynamic images,
so I want it to be able to run a long time, but at 1 image/minute it will
consume 1.5MB per day that the JSP engine is up. This is absurd. It seems that
no package should use "deleteOnExit()" dynamically - it guarantees a memory
leak. In a long-running system like a JSP engine, this is completely unacceptable.
It would be better if the temporary file were deleted when the image data was
garbage collected, or some such, so there was no need to allocate a struct
dlEntry in the native code.
(Review ID: 133570)
======================================================================
Its possible to solve the ImageIo problem if there is a version of
deleteOnExit that returns a unique identifier. Clients such as ImageIO
who remove the file before exit can then call an API to remove the
file referenced by that unique identifier from the internal list of
files to delete on exit.
long deleteOnExit2()
public static void removeFromDeleteList(long)
###@###.### 2003-04-02
============================
- duplicates
-
JDK-6291034 FileCacheImageInputStream and FileCacheImageOutputStream should avoid File.deleteOnExit
- Resolved
- relates to
-
JDK-4872014 File.cancelDeleteOnExit() to avoid JVM crashes
- Open
-
JDK-4809375 File.deleteOnExit() should be implemented with shutdown hooks
- Resolved
-
JDK-6188718 File.deleteOnExit() - "Clean up and return" after JNU_ThrowOutOfMemoryError
- Resolved