Thanks a lot, Clemens, for looking into this!
Dmitri
[EMAIL PROTECTED] wrote:
Clemens, you were right... I am ashamed. I thought I
was cleaning
that reference, while I was actually not. I guess I
over-sought this
possibility simply because everything was working
fine with OSXImage
Clemens, you were right... I am ashamed. I thought I
was cleaning
that reference, while I was actually not. I guess I
over-sought this
possibility simply because everything was working
fine with OSXImage
or awt.ToolkitImage (even though the reference was
not cleaned up).
Thanks a
I am having problems reclaiming memory consumed by a
(supposedly
GC'ed) BufferedImage. When I want to dispose of an
image, I basically
do:
That's because in Java you never explicitly reclaim memory.
img.flush();
img = null;
Nice, but rather pointless.
I was expecting this to
Hello,
I am having problems reclaiming memory consumed by a (supposedly
GC'ed) BufferedImage. When I want to dispose of an image, I basically
do:
img.flush();
img = null;
I was expecting this to free the memory from all resources associated
with this BufferedImage. Unfortunately it does
Just to be curious: Does the problem also happen if you call
setAccelerationPriority(0) on the buffered image right after construction?
lg Clemens
[Message sent by forum member 'linuxhippy' (linuxhippy)]
http://forums.java.net/jive/thread.jspa?messageID=246520
On 21 nov. 07, at 12:56, [EMAIL PROTECTED] wrote:
Just to be curious: Does the problem also happen if you call
setAccelerationPriority(0) on the buffered image right after
construction?
lg Clemens
Yes, it does happen. No difference. I tried both on my Mac and on the
Windows machine
Well you could try to create a heap-snapshot using jconsole
(MBeans-com.sun.management-Hotspot-diagnostics-dumpHeap)
and later view it using jhat.
You should be able to follow the references to the BufferedImages.
For the first time it sounds complicated, but those free tools are a great help
On 21 nov. 07, at 14:25, [EMAIL PROTECTED] wrote:
Well you could try to create a heap-snapshot using jconsole (MBeans-
com.sun.management-Hotspot-diagnostics-dumpHeap)
and later view it using jhat.
You should be able to follow the references to the BufferedImages.
For the first time it sounds
Do you draw anything on the images? I seem to remember having a similar
problem and I think I got the Graphics Context from the image to draw on it,
and had a problem until I added gc.dispose(). I'm not sure, I can't seem to
locate the code.
[Message sent by forum member 'cobrien' (cobrien)]
On 21 nov. 07, at 15:14, [EMAIL PROTECTED] wrote:
Do you draw anything on the images? I seem to remember having a
similar
problem and I think I got the Graphics Context from the image to
draw on it,
and had a problem until I added gc.dispose(). I'm not sure, I
can't seem to
locate the
Eventually that is probably what I will do. But I was
wondering if I
was missing something obvious to actually dispose of
all resources
associated with the BufferedImage
By default you don't need to care about BufferedImages - if you don't hold any
references it up to the GC to free
On 21 nov. 07, at 15:36, [EMAIL PROTECTED] wrote:
Eventually that is probably what I will do. But I was
wondering if I
was missing something obvious to actually dispose of
all resources
associated with the BufferedImage
By default you don't need to care about BufferedImages - if you
don't
I've put the 2 JAR files at [1,2]. Here is the
associated command line:
java -jar zslideshow-0.1.0-SNAPSHOT.jar
I tried it but the only thing I can see is a colored bar showing the
heap-useage on Linux (which remains constant). I guess I am using it in the
wrong way, or are maybe some images
On 21 nov. 07, at 20:12, [EMAIL PROTECTED] wrote:
I've put the 2 JAR files at [1,2]. Here is the
associated command line:
java -jar zslideshow-0.1.0-SNAPSHOT.jar
I tried it but the only thing I can see is a colored bar showing
the heap-useage on Linux (which remains constant). I guess I am
Hi Emanuel,
It seems your application still holds references to that image:
[EMAIL PROTECTED] (37 bytes) :
[EMAIL PROTECTED] (165 bytes) :
[EMAIL PROTECTED] (24 bytes)
[Ljava.util.Hashtable$Entry;@0x6a6a77b8 (1540 bytes)
[EMAIL PROTECTED] (40 bytes)
[EMAIL PROTECTED] (91 bytes) : field
One thing to note - img.flush() doesn't dispose or free the image - it only
gets rid of cached resources. So the things it gets rid of are:
- For a Toolkit image, it gets rid of the in-memory representation, which can
be rebuilt by reloading the image from the source if you use it again.
-
On 21 nov. 07, at 21:09, [EMAIL PROTECTED] wrote:
Hi Emanuel,
It seems your application still holds references to that image:
[EMAIL PROTECTED] (37 bytes) :
[EMAIL PROTECTED] (165 bytes) :
[EMAIL PROTECTED] (24 bytes)
[Ljava.util.Hashtable$Entry;@0x6a6a77b8 (1540 bytes)
[EMAIL PROTECTED]
17 matches
Mail list logo
