Possible Bug in Garbage Collector?

Hello all
I'm new to these forums but I searched for this problem and couldn't find exactly the same thing - apologies if I missed something.
I've written an image browser which displays thumbnails, and when you click on a thumbnail it loads the image in a new window. This new window is just a JFrame, with a single JLabel, with an ImageIcon in it, representing the picture. The path name of the picture is passed when this JFrame is created, and the picture is loaded within the JFrame. Therefore, when I close the JFrame, I expect the memory associated with the image to disappear.
This works. However, when I open a fairly large image (around 1500x1500 pixels), and then close the window, the garbage collector doesn't free the memory. After this, if i continue to open windows with smaller images, they too have the same problem. However, this doesn't happen with smaller images until I open a larger image.
I think this is a problem with the garbage collector, is this familiar to anyone? Can anyone help? Unfortunately I can't really paste code since this is a university assignment. But you can try it - just load a jframe with a large picture, close it, and as long as the program runs the memory will not be deallocated.
Any help would be massively appreciated.
Thanks

Since you're not willing to post your code it's very hard to comment.
One question: Are you calling System.gc() after closing these frames? In fact you should probably call it 3 times to make sure the garbage collector takes you seriously. Try this and let us know if you're still showing the leak

Similar Messages

Is it possible to run garbage collector in publisher instance with out opening a tunnel?

Hi,
In General we are running garbage collector in publisher by opening a tunnel.
is there any alternate way to do that.
we installed adobe cq5 on solaris10.
thanks,
vidhyadhar

Check out - http://dev.day.com/docs/en/crx/current/administering/persistence_managers.html#Automating Garbage Collection
Example of curl command that will start up garbage collection. You can create a sheel script with the curl command and set it up to run as cron job on the publish server which should solve your problem.

Optimization of the JVM memory - Garbage Collector

Hi ,
Just a question about JVM memory management.
There is memory limitation of memory usage limitation (1.6M) in JVM.
Is there any possibility to use "Garbage collector" mechanism to optimize the memory usage?
Or any suggestions for the JVM memory optimization?
Thanks a lot!!!

nicolasmichael wrote:
Hi,
the "memory limitation" does not have anything to do with garbage collection, but with the address space your operating system provides. On a 32bit operating system, your virtual address space is limited to <= 4 GB, depending on your operating system (for example 1.something GB on Windows and 3.something GB on Solaris). No.
Windows 32 bit has a 2 GB application space and can be configured to allow a 3GB space.
The Sun VM does not allow more because of the way that the executable is linked.
[http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4358809]

Is it possible to disable the garbage collector?

I was just wondering if it's possible to disable the garbage collector... Thank you.

Try running with the -Xnoclassgc parameter.
http://java.sun.com/developer/JDCTechTips/2004/tt0420.html#2

I have a memory leak, objective-c 2.0, and garbage collector...

the code i am using is a modification of the code/problem found in "Cocoa with Objective-C", chapter 3.
i have tried to use the objective-c 2.0 garbage collector methodology, using @property, @synthesize, etc. when i run the code as listed below i get a leaking message.
[Session started at 2008-02-01 23:33:37 -0500.]
2008-02-01 23:33:38.070 SongsFoundationTool[28876:10b] * _NSAutoreleaseNoPool(): Object 0x2040 of class NSCFString autoreleased with no pool in place - just leaking
Stack: (0x96b10178 0x96a3e0f8)
2008-02-01 23:33:38.075 SongsFoundationTool[28876:10b] Song 1: We Have Exposive
2008-02-01 23:33:38.076 SongsFoundationTool[28876:10b] * _NSAutoreleaseNoPool(): Object 0x2060 of class NSCFString autoreleased with no pool in place - just leaking
Stack: (0x96b10178 0x96a3e0f8)
2008-02-01 23:33:38.078 SongsFoundationTool[28876:10b] Song 2: Loops of Fury
The Debugger has exited with status 0.
when i include the commented out section, in the implementation file section, the description method, and use song1 and song2, in main, instead of song1.name and song2.name the program seems to run fine.
The Debugger has exited with status 0.
[Session started at 2008-02-01 23:38:24 -0500.]
2008-02-01 23:38:24.375 SongsFoundationTool[28936:10b] Song 1: We Have Exposive
2008-02-01 23:38:24.379 SongsFoundationTool[28936:10b] Song 2: Loops of Fury
The Debugger has exited with status 0.
please help me understand what's happening here.
also, why was it necessary to use
@property(copy, readwrite) NSString *name;
@property(copy, readwrite) NSString *artist;
instead of
@property(readwrite) NSString *name;
@property(readwrite) NSString *artist;
thanks everyone, the code is below.
// ....................... header file ...............
#import <Cocoa/Cocoa.h>
@interface Song : NSObject {
NSString *name;
NSString *artist;
@property(copy, readwrite) NSString *name;
@property(copy, readwrite) NSString *artist;
@end
//.................... the implementation file ..................
#import "Song.h"
@implementation Song
@synthesize name;
@synthesize artist;
-(NSString *) description
return [ self name ];
@end
//................................ main............................
#import <Foundation/Foundation.h>
#import "Song.h"
int main (int argc, const char * argv[]) {
Song *song1 = [ [ Song alloc ] init ];
song1.name= @"We Have Exposive" ;
[ song1 setArtist: @"The Future Sound Of Londown" ];
Song *song2 = [ [ Song alloc ] init ];
[ song2 setName: @"Loops of Fury" ];
[ song2 setArtist: @"The Chemical Brothers" ];
// Display Object
NSLog( @"Song 1: %@", song1.name );
NSLog( @"Song 2: %@", song2.name );
// include statements below if -description method is uncommented
// then comment out the two statements above. no memory leak if the code
// is used from the statements below and - description is not commented out and
// the two NSLog statements above are commented out.
NSLog( @"Song 1: %@", song1 );
NSLog( @"Song 2: %@", song2 );
return 0;
}

Normally, your main only has a call to NSApplicationMain(). If you aren't doing a traditional MacOS X application, you will still want at least NSApplicationLoad() to get enough of the runtime to avoid those messages.
I don't know for sure about the syntax of Objective-C 2.0. That stuff is all new. What error message are you getting that indicated that (copy, readwrite) is required? Could you provide a link to the actual example source? I did a quick check and assign and readwrite are the defaults. It is possible that readwrite by itself makes no sense. But I'm just guessing.

Garbage Collector blocks - weird behaviour

Hi!
After launching an application we ran into weird problems with the garbage collector. It's a combo of Jetty/JGroups/Helma-Application-Server and various other libraries on a RedHat 7.3 box. The problem occurs on a machine with relativly high load (~10 requests/sec) but doesn't come along with high load automatically.
After some hours uptime the garbage collector blocks for increasingly longer intervals until the application is reachable only for seconds every few minutes. In concerns exclusivly minor GC in the new space. Each stop lasts for just 1/10000 seconds but that in a loop of 1000s times back-to-back.
The logfile created by the -Xloggc option looks like this:
20085.784: [GC 20085.785: [ParNew
Desired survivor size 32768 bytes, new threshold 0 (max 0)
: 71552K->0K(71616K), 0.0634410 secs] 380477K->312523K(511936K), 0.0639970 secs]
Total time for which application threads were stopped: 0.0652310 seconds
Application time: 8.7885840 seconds
Total time for which application threads were stopped: 0.0005810 seconds
Application time: 0.0005620 seconds
Total time for which application threads were stopped: 0.0006080 seconds
Application time: 0.0002630 seconds
Total time for which application threads were stopped: 0.0004410 seconds
Application time: 0.0001790 seconds
Total time for which application threads were stopped: 0.0005480 seconds
Application time: 0.0001670 seconds
Total time for which application threads were stopped: 0.0003440 seconds
Application time: 0.0001210 seconds
Total time for which application threads were stopped: 0.0004450 seconds
Application time: 0.0001590 seconds
Total time for which application threads were stopped: 0.0004220 seconds
Application time: 0.0002180 seconds
20095.265: [GC 20095.265: [ParNew
Desired survivor size 32768 bytes, new threshold 0 (max 0)
: 71552K->0K(71616K), 0.0753260 secs] 384282K->317322K(511936K), 0.0759450 secs]
Total time for which application threads were stopped: 0.0767720 seconds
Application time: 0.3346050 seconds
While the "Total time.." lines were printed, the app was unreachable. "Application time" usually marks the time the app was running between two garbage collections. It seems as if the garbage collector tries to stop the app, can't do it for whatever reason and tries again a moment later.
We've tested any suitable garbage collector, we've tried out j2sdk1.4.2_02, j2sdk1.4.2_07, jdk1.5.0_01, jdk1.5.0_02, we've tried different machines to exclude hardware failure. It is hard to reproduce in a test environment but we've seen a few lines like above on a windows box too (no longer blocking times, tough). There aren't any OutOfMemoryErrors, the heap management looks fine. After GC about 3/4 of the heap are freed even while the above problem occurs, so we're ruling out a memory leak.
Maybe someone here has stumbled across that problem or has any ideas what could trigger such a behaviour? After two weeks of debugging I've run out of ideas on where to look for a bug.
Yours remotely,
Stefan

hi there
Can u add -XX:+PrintHeapAtGC -XX:+PrintGC and show the portion of the log files?
You are using the -XX:+ParNewGC? Any -XX:+UseConcMarkSweepGC?
Also, add -XX:+DisableExplicitGC
Hope this helps.

Garbage collector question

I have a question about the garbage collection. You cant activate the garbage collector when you want but in JProbe tool you can request it pushing a button. Can i do this in my application?. I tried using System.gc() and Runtime.getRuntime.gc() but i cant get the same result. Any ideas?
Thanks in advance and excuse me, my english is not so good.

In Jprobe if you request a garbage collection you get
a deep garbage collection that release much of the
used heap size. But if i put in my code System.gc()
only a little of space is released.The amount of released memory depends of course on the number of "unused" objects. If you allocate an array of bytes that's allmost the maximum size of the heap the JVM can use and you make it available for garbage collection by releasing the refernce the effect running the garbage collector is much bigger than if you only allocate an array of, let's say 32 bytes, and do the same. A complex GUI application allocates and releases lots of objects so it's possible to release a huge amount of heap space whereas a not so compex application uses fewer objects and there are less object to release by the garbage collector.

GARBAGE COLLECTOR( NOT ACTIVATING)

I AM CERTIFIED, LEARNED IN THE COURSE THAT THE GARBAGE COLLECTOR IS A SYSTEM THREAD WHICH RUNS AND COLLECTS ALL THE UN-REFERENCED OBJECTS BUT I COULDN'T MANAGED TO ACTIVATE IT:
THE PROBLEM IS DEFINED AS FOLLOWS:-
1. WE KNOW THAT IF WE OVERRIDE THE FINALIZE METHOD OF AN OBJECT THEN IT IS CALLED WHEN THE SPECIFIC OBJECT IS GARBAGE COLLECTED.
THATS WHY I OVERRIDED A CLASS'S FINALIZE METHOD AND ISSUED A PRINTLN STATEMENT
2. THEN AT RUNTIME I INSTANTIATED THE OBJECT OF THAT PARTICULAR CLASS .
3. I SET THE REFERENCE TO NULL.( AT RUNTIME )
4. NOW ACCORDING TO THE DOCUMENTATION THE OBJECTED SHOULD BE GARBAGE COLLECTED AFTER SOMETIME BUT I WAITED FOR A ABOUT TEN MINUTES BUT IT ISN'T.
PLEASE ANSWER THIS QUESTION AN IF POSSIBLE EXPLAIN THE MECHANISM BY WHICH THE FINALIZE METHOD IS CALLED AT RUNTIME
IT SHOULD BE NOTED THAT THIS THREAD RUNS IN LOW MEMORY CONDITIONS BUT SINCE IT IS A LOW PRIORITY THREAD HOW CAN IT MANAGES TO RUN IN LOW MEMORY CONDITIONS

The only purpose finalize should be used for is a last ditch effort to free resources other than memory allocation. That said...
-It should NEVER be used to free a resource that is not automatically freed when the application exits. So for example it could be used to close a socket, but it should not exist when the 'resource' is a file.
-It should NEVER be the only way to free a resource. There is a reason I said "last ditch". The user of the object should have an explicit method to call which frees the resources.
And that said I would never use it regardless even for a last ditch cleanup. The reason for that is that it would tend to hide the improper usage of the class - in other words that the user wasn't calling the correct clean up method. I might use it to put a diagonistic (probably an unchecked exception) which indicates that the resource was not cleaned.
Expanding further on the other comments made here, if you read the spec you will find that the language does not guarantee that finalize will be called. All that it guarantees is that if it is called it will only be called once. In addition finalize can reduce performance because the existance of it might (and probably will) force the garbage collector to do two passes on the object rather than just one.

Garbage Collector behaviour

It seems that the only requirement of a garbage collector is that it must cleanup some unreferenced objects when the system is low in memory. Aside from that, is there anywhere that documents in some detail what the garbage collector will actually do for a specific version of the VM, specifically 1.3.1?
I am interested in knowing:
1) Does the GC periodically run cleanups? If so, when? Does it cleanup all unreferenced objects, or only some? How does it decide? etc.
2) How does the GC respond to calls to System.gc()? Will it do a thorough cleanup or half-hearted? Will it cleanup right away? etc.
3) Is there any delay between marking an object for cleanup and running the finalize method?
4) How does the GC respond to calls to Runtime::runFinalization()?
Thanks,
-Brian

1) Does the GC periodically run cleanups?Basically yes.
If so, when?Randomly. It isn't defined. When the JVM starts to run down with memory, gc will more likely run, but it's not guaranteed.
Does it cleanup all unreferenced objects, or only some?Randomly; It runs in a background thread, and may stop frequently.
2) How does the GC respond to calls to System.gc()?It'll schedule it to run, but nothing guarantees that it actually will run.
Will it cleanup right away?Definitely not. Maybe it'll start it, it even possible that it'll do all of it, but equivalently possible that won't cleanup anything. No way to tell.
3) Is there any delay between marking an object for
cleanup and running the finalize method?Yup, the delay might be anything from almost zero to infinite time.
It is even possible that your program stops before the gc would ever
finalized one single object.
4) How does the GC respond to calls to
Runtime::runFinalization()?Well, this is a weak request that you're going to run finalizations, but
nothing will guarantee that it actually will happen.
The best you can do is never provide finalize() methods, and even if you do, do not trust that they'll ever run!
The only advise I can give: forget that such animal as "garbage collector" exists.

Garbage Collector seems not to run

Hi!
I have a problem with the garbage collector:
To free memory, I regularly run the garbage collector in my app ( System.gc() ) after releasing resources by setting the reference variable to "null". But after some time I get an "out of heap memory" error. It seems that the gc doesn't run - I get the following result on the stdout:
0 garbage collections (0 bytes collected)
Is this possible? Or can I fix this problem?
Thanks for your help

Is it that the GC was not kicking-in even when you delete the references to the objects? That is true for any GC. GC will kick in only when you need more memory to create new objects
Also, you need to tune your young generation space and increase it from default 2MB to 32MB which will avoid frequent young generation GCs. By setting Xmx to 1024 MB, VM will try to grow till 1024 MB and if it can't allocate because
of less physical memory on your system, it will throw OutOfMemory errors.
I suggest you try the following:
1. Configure young generation to 32MB and old generation to 512 MB. This is how
you start your app
java -XX:MaxNewSize=32m -XX:NewSize=16m -Xms64m -Xmx512m -verbose:gc <app>
This sets the initial heap size to 64MB. You can increase this if your initial startup memory requirement (static memory) is higher that 64MB.
With Xmx set to 512MB, if some sessions die or are closed and heap size grows to 512MB, Full GC should kick in and you should be able to release memory for new sessions. Running with -verbose:gc will show if Full GC gets kicked in or not.
2. Try can calculate the static memory required at any point of time and also how much garbage is collected in certain time period. Then using these values we can make changes in young and old generation sizes.

Garbage Collector in 5.0

I have nevver known, how the garbage collector internally works. Now a memory problem forces me to understand it. I read several articles but I do not understand them.
I have a simple question:
Is it possible, that my application will get an OutOfMemoryError even if a garbage-collect would free most of the memory?
In other words:
Is it assured, that garbage collector will always run before an OutOfMemoryError occurs?
I have an application, which parses hundreds of MB of data. However it is assured, that parsed data wont be hold in memory for long time. Normally my application would run with less then 64 MB.
In Java 1.4.2 I have not encountered any memory problems. But in Java 5.0 I encountered the following problem:
My application runs a very long period of time. During this time, the memory usage is about 16 MB. After that period the memory usage suddenly increases and does not stop increasing until a OutOfMemory Error occurs (this is mostly about 260 MB if I set -Xmx265m).
I am sure that I do not hold references to that much data in my application.
Why does the garbage collector not free the memory?
Is the garbage collector in 5.0 different from the one in 1.4.2? If yes, can I set the garbage collector to be that one of 1.4.2???
Thanks and regards
Fatih Coskun

Is it assured, that garbage collector will always run
before an OutOfMemoryError occurs?Yes, an OutOfMemoryError is the GC failing to free enough memory.
Why does the garbage collector not free the memory?
Is the garbage collector in 5.0 different from the one
in 1.4.2? If yes, can I set the garbage collector to
be that one of 1.4.2???Tiger (JDK 5.0) has introduced some "ergonomics" based on the machine the application is run on:
http://java.sun.com/j2se/1.5.0/docs/guide/vm/gc-ergonomics.html
Also, you may want to use jconsole and other new tools in tiger:
http://java.sun.com/j2se/1.5.0/docs/tooldocs/index.html#debug
-Alexis
>
Thanks and regards
Fatih Coskun

Garbage Collector - which one?

How can I tell which Garbage collector is being invoked?
I'd like proof that serial or parallel is indeed running.

Which version of the platform are you running?
If you run with the -XX:+PrintGCDetails flag, when a collection happens it will print a line like [GC [PSYoungGen: 184K->128K(10752K)] 184K->128K(35328K), 0.0145377 secs] where the "PSYoungGen" indicates that you are using the parallel young generation scavenger. If it instead says [GC [DefNew: 1791K->192K(1984K), 0.0146794 secs] 1791K->1706K(6080K), 0.0148851 secs] then "DefNew" says you are using the default serial young generation collector. Other variations are possible depending on which collector you are running. But those are the two you asked about.
This, and much more, is described in http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html or http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html depending on what version of the JDK you are running. There's also http://java.sun.com/javase/technologies/hotspot/gc/memorymanagement_whitepaper.pdf for background reading. (Hey, we write these things, we might as well encourage people to read them.)

Redirect garbage collector output to a historical file

Hello to you all,
I know how to redirect the garbage collector output to a file with the parameter -Xloggc:<file> but there is a problem: Everytime the jvm is rebooted, that file is reset, deleting all the information generated before.
I would like the jvm to append the new information to that file instead of deleting the old one.
Is there anyway to configure the jvm to do that?

Hi you all again,
Probably I didn't explain my problem correctly in the previous post.
I'm using J2SDK 1.4.1_02 on a Windows 2K SP1 platform .
I've read the JVM documentation and I've learnt a lot about tuning garbage collection but almost nothing about how to solve the problem I have.
I know how to generate the verbosegc output with the parameter '-verbosegc' and how to redirect it to a file with the parameter '-Xloggc:<file>' but everytime the JMV is restarted the content of that file is deleted.
Is it possible to append content to that file instead of overwriting it and can anyone give me a clue to do this?
Thank you in advance.

Garbage Collector & references

Hi there,
is there any possibility to determine in a class "B" if an instance of class "A" just exists because of a reference in class "B" and is not referenced from elsewhere?
That is, is there a possibility to determine how many references exist for a certain instance?
Sincerely
Karlheinz Toni

Because I do not really get how the garbage collector works and all the why's and when's memory is freed.
I am doing a xml/xslt Application beeing rather memory consuming (:(). If I try to work with 3-5 files at once each about 50Mb memory runs out :). So I would like to be able to delete all the objects at once if they are not needed anymore.
I thought like this:
1.) you could check every time after you used a object if there are still more than one reference.
2.) If not you've got the only one => free it
Just a thought. Can you imagine a better way (if yes what is it? :)
Thx
Sincerely
Karlheinz Toni

JNI - Garbage Collector Problem ?

Hi,
I've got a JNI methode, which ceate and lauch a Process in c++ (a process to make VoIP).
- this methode is returning an int=the pointer to the instance (which implement this process) so that othet JNI methode can have access to the main instance.
Under windows, everything works fine, but
Using linux:
I add a memory wathcher on my program to see the memory used by the application / memory available for the JVM.
The memory used by the application is growing (this is normal at this point), but when the GC is callled (by the system) the Java application is frozen (no error message), and I have to kill it. On the oter side, the Dll is running normally !
My theory is that under Linux, the GC is "feeing" the memory used by the c++ process , then java is trying to write on it, but have no access, or somehing like that.
Is there any option to be check this theory: as Java is retunring no error, but just freezing, it is not very clear to understand.
I tried, using JNI, but removing the Process in it, just calling a basic operation, and there is no bug.
Is there a special procedure to do on LINUX, for managing the Garbage Collector with JNI ?
Here is a piece of code :
/***********Java Side******************/
//The JNI def:
public class JNIWrapper {
     public JNIWrapper() {
     // create the h323 Process
public native int create();
///The class managing the JNI methodes and containing the pointer to the dll main class
public class CallControlH323 implements CallControl {
     int h323StackPtr; //Pointer to the h323stack, needed in the c++ side
     JNIWrapper myJNIWrapper;
     String options; //option for the CallControl configuration
     public CallControlH323(){
          myJNIWrapper = new JNIWrapper();
     public void configure(String options, String codecs) {
          h323StackPtr = myJNIWrapper.create();
/*************************C++ side*****************/
//JNI functions (file JNITerminal.cxx)
#include "JNITerminal.h"
#include <stdio.h>
// Java Global Variables
jobject jobj;
JavaVM *jvm;
/** Create the MainInterface **/
JNIEXPORT jint JNICALL Java_ca_sess_voicesess_terminal_JNIWrapper_create
     (JNIEnv *env, jobject obj)
     // Make object a Global Reference
     jobj = env->NewGlobalRef(obj);
     // Get Java VM
     env->GetJavaVM(&jvm);
     //create and start the main Process
     MainInterface * mainInterface;
     mainInterface = new MainInterface();
     return ( ( jint ) mainInterface );
MainInterface inherite from PProcess (from Pwlib), it is the top process of the dll application
MainInterface::MainInterface():PProcess("", "", MAJOR_VERSION, MINOR_VERSION, BUILD_TYPE, BUILD_NUMBER)
#ifdef MSCVER
#pragma warning(disable:4355)
#endif
#ifdef MSCVER
#pragma warning(default:4355)
#endif
     ShowOutputs("H323Lib: Create Main Interface");
void MainInterface::Main () {}
MainInterface::~MainInterface()
/////////////////////////////////////////////////////////////////////////7
If you have any suggestion, comment, help, don hesitate !!
Thanks for your help
Bart

I also added the option -verbosegc to the java command.
I noticed that the bug arrived after a Full gc:
[Full GC 23301K->12351K(24844K), 0.3737040 secs]

Possible Bug in Garbage Collector?

Similar Messages

Maybe you are looking for