Strange garbage collector behaviour

Hello,
I am seeing quite a strange behaviour from the garbage collector in one of our applications.
The application is a standalone Java app, it receives requests over a TCP socket and responds to them. It is basically a kind of a cache before the database. There is a constant request flow of 10-100 requests per second. Average response time is below 50ms. It is running on a multiprocessor Sun machine, JDK 1.4.1_02.
The problem arises when the app has been running for a while. Depending on the allowed maximum memory size - with 256mb after about half a day, with 512mb after about a day, the garbage collector seems to be running most of the time. We turned on GC logging and from the log I can see that initially for a long period only the DefNew collector is used. The GC times are ~0.05sec then. Then after some time old generation collections start taking place. These collections take 3-4 seconds. The old gen collections then become more frequent until all that is going on, is one collection after another. About 3-4seconds for the collection, then after another 3-4 seconds the same thing again.
Can anyone please help in understanding what can cause this kind of behaviour? I am quite sure that the app is stable in a sense that it doesn't start to eat up extra memory at some point.
Any help greatly appreciated,
erik
Here are some excerpts from the GC log:
After startup:
100.264: [GC 100.264: [DefNew: 83488K->1290K(84800K), 0.0487560 secs] 87278K->5080K(259584K), 0.0490613 secs]
107.439: [GC 107.439: [DefNew: 83530K->1299K(84800K), 0.0526107 secs] 87320K->5178K(259584K), 0.0528313 secs]
111.554: [GC 111.554: [DefNew: 83539K->1207K(84800K), 0.0539021 secs] 87418K->5230K(259584K), 0.0541348 secs]
119.724: [GC 119.724: [DefNew: 83447K->1359K(84800K), 0.0561691 secs] 87470K->5382K(259584K), 0.0564463 secs]
125.576: [GC 125.576: [DefNew: 83599K->1366K(84800K), 0.0622342 secs] 87622K->5504K(259584K), 0.0624880 secs]
130.987: [GC 130.987: [DefNew: 83606K->1331K(84800K), 0.0586104 secs] 87744K->5607K(259584K), 0.0588732 secs]
138.695: [GC 138.695: [DefNew: 83571K->1296K(84800K), 0.0588720 secs] 87847K->5697K(259584K), 0.0591136 secs]
144.413: [GC 144.413: [DefNew: 83536K->1246K(84800K), 0.0607789 secs] 87937K->5790K(259584K), 0.0612128 secs]
150.661: [GC 150.661: [DefNew: 83486K->1279K(84800K), 0.0486299 secs] 88030K->5823K(259584K), 0.0488933 secs]
157.186: [GC 157.187: [DefNew: 83519K->1410K(84800K), 0.0545036 secs] 88063K->5954K(259584K), 0.0547557 secs]
162.937: [GC 162.937: [DefNew: 83650K->1230K(84800K), 0.0590144 secs] 88194K->5998K(259584K), 0.0592747 secs]
171.555: [GC 171.555: [DefNew: 83470K->1334K(84800K), 0.0554568 secs] 88238K->6101K(259584K), 0.0557090 secs]
175.416: [GC 175.416: [DefNew: 83574K->1315K(84800K), 0.0584964 secs] 88341K->6178K(259584K), 0.0587433 secs]
182.616: [GC 182.616: [DefNew: 83555K->1307K(84800K), 0.0709417 secs] 88418K->6234K(259584K), 0.0712034 secs]
And then in the end:
13177.7: [GC 13177.7: [DefNew: 82240K->82240K(84800K), 0.0000487 secs]13177.7: [Tenured: 95861K->96094K(174784K), 3.7160279 secs] 178101K->96094K(259584K), 3.7165109 secs]
13183.9: [GC 13183.9: [DefNew: 82240K->82240K(84800K), 0.0000459 secs]13183.9: [Tenured: 96094K->96268K(174784K), 3.6973634 secs] 178334K->96268K(259584K), 3.6978356 secs]
13193: [GC 13193: [DefNew: 82240K->82240K(84800K), 0.0000534 secs]13193: [Tenured: 96268K->95923K(174784K), 4.6233189 secs] 178508K->95923K(259584K), 4.6237995 secs]
13201.2: [GC 13201.2: [DefNew: 82240K->82240K(84800K), 0.0000531 secs]13201.2: [Tenured: 95923K->96100K(174784K), 3.7120306 secs] 178163K->96100K(259584K), 3.7125165 secs]
13208.6: [GC 13208.6: [DefNew: 82240K->82240K(84800K), 0.0000502 secs]13208.6: [Tenured: 96100K->96268K(174784K), 3.6950267 secs] 178340K->96268K(259584K), 3.6955072 secs]
13218.1: [GC 13218.1: [DefNew: 82240K->82240K(84800K), 0.0000582 secs]13218.1: [Tenured: 96268K->96442K(174784K), 3.7476890 secs] 178508K->96442K(259584K), 3.7481875 secs]
13225.8: [GC 13225.8: [DefNew: 82240K->82240K(84800K), 0.0002743 secs]13225.8: [Tenured: 96442K->96200K(174784K), 4.9092106 secs] 178682K->96200K(259584K), 4.9103437 secs]
13234.4: [GC 13234.4: [DefNew: 82240K->82240K(84800K), 0.0000541 secs]13234.4: [Tenured: 96200K->96409K(174784K), 3.7423712 secs] 178440K->96409K(259584K), 3.7428506 secs]
13240.6: [GC 13240.6: [DefNew: 82240K->82240K(84800K), 0.0000528 secs]13240.6: [Tenured: 96409K->96633K(174784K), 3.6245501 secs] 178649K->96633K(259584K), 3.6250124 secs]
13273.7: [GC 13273.7: [DefNew: 82240K->82240K(84800K), 0.0000651 secs]13273.7: [Tenured: 96633K->96799K(174784K), 3.7021988 secs] 178873K->96799K(259584K), 3.7027242 secs]
13283: [GC 13283: [DefNew: 82240K->82240K(84800K), 0.0000510 secs]13283: [Tenured: 96799K->96620K(174784K), 4.9944806 secs] 179039K->96620K(259584K), 4.9949444 secs]
I can provide the whole log if neccessary.

The most likely cause of this problem is a memory leak in your application. As the memory reaches close to its limit the GC has to run for longer, more often to get free memory.
The runtime before going slow being proportional to the memory size.
Can you have the program log the System.freeMemory() and System.totalMemory()

Similar Messages

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 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

Bonjour à la communauté Adobe et merci pour les
éventuelles réponses que je trouverai grâce à
vous.
Je relance je pense une fois de plus, comme sur de nombreux
forums, le problème du Garbage Collector.
J'ai un MovieClip crée dynamiquement. Ce MovieClip
contient un objet vidéo contrôlé et géré
dynamiquement via une classe (cette partie n'est pas bien
importante je suppose); bref je voudrais pouvoir supprimer
complètement ce clip, mais même après un
"removeChild(clip)" et un "clip = null", j'entend toujours le son
de la vidéo... ce qui me fait dire qu'il est toujours
matériellement présent, mais pourquoi??
mon code :
var mavideo:MovieClip;
mavideo = new monclip();
addChild(mavideo);
removeChild(mavideo);
mavideo = null;
System.gc();//j'ai même essayé de forcer le Garbage
Collector, sans succès.
Voilà donc ma question globale : comment supprimer
complètement un clip en as3?
Sorry for my bad english, but the question is : how to
completely delete a MovieClip using AS3? If I remove a MovieClip
which include a video, with the code below, i don't see the video
anymore but i can hear the sound... Strange, isn't it?

Bonjour à la communauté Adobe et merci pour les
éventuelles réponses que je trouverai grâce à
vous.
Je relance je pense une fois de plus, comme sur de nombreux
forums, le problème du Garbage Collector.
J'ai un MovieClip crée dynamiquement. Ce MovieClip
contient un objet vidéo contrôlé et géré
dynamiquement via une classe (cette partie n'est pas bien
importante je suppose); bref je voudrais pouvoir supprimer
complètement ce clip, mais même après un
"removeChild(clip)" et un "clip = null", j'entend toujours le son
de la vidéo... ce qui me fait dire qu'il est toujours
matériellement présent, mais pourquoi??
mon code :
var mavideo:MovieClip;
mavideo = new monclip();
addChild(mavideo);
removeChild(mavideo);
mavideo = null;
System.gc();//j'ai même essayé de forcer le Garbage
Collector, sans succès.
Voilà donc ma question globale : comment supprimer
complètement un clip en as3?
Sorry for my bad english, but the question is : how to
completely delete a MovieClip using AS3? If I remove a MovieClip
which include a video, with the code below, i don't see the video
anymore but i can hear the sound... Strange, isn't it?

Swing components and the garbage collector

How much care does one need to take with swing components, with reference to running out of stack space? I ask because I'm writing a system for an automotive parts company, and the company tends to not reboot the machines very often...
Anyway... if a JFrame is closed, is it and all its components marked for GCing? Do I need to call the dispose method, or is this part of the default close behaviour? Or is there something else entirely?
Cheers

In class that calls for .setVisible(false) of one JFrame u MUST call
for dispose() method.
so
myFrame.setVisible(false)
myFrame.dispose()
myFrame = null // to help the garbage collector
If u have classes that becames from JFrame (or JDialog) u can
invoke in its constructors:
this.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE)
This makes uncecessary to call for dispose() method explicetly.
If u do not have this kind of classes u can invoke this method
after u have create your JFrame
JFrame myFrame = new JFrame();
myFrame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE)
The most important thing is REMOVE ALL LISETNERS that u have added, so, if u have classes that becames from JFrame u can ovverride
the dispose method to do that
eg
public void dispose()
super.dispose()
removeActionListener(.....)
and so on
If u do not have this kind of classes u must remove all listeners u have
added before u invoke the setVisible(false) method.
Regards

Garbage Collector Questions

Howdy all,
I've got a few questions about flash's garbage collector. I'm building a game and have all elements in a container sprite called _gameContainer.
_gameConatiners contains other sprites such as _hudContainer which contains more containers such as _gameoverContainer, _menuContainer, etc. So there's a whole hierarchy of containers that are all contained in _gameContainer which is added directly to the document class (not the stage btw).
So the whole thing should basically be Stage -> Document Class -> _gameContainer -> etc.
When the player loses or wants to restart the game, I'm removing all event listeners (which are defined as weak, but still rather make sure there's no loose ends), stopping all music/sounds, removing _gameContainer from the stage, and then setting _gameContainer to null.   From there I am re-calling my init function which creates everything (_gameContainer, and everything inside of it, as well as creating all the standard eventlisteners).
Am I doing everything upside down? Is this *a* proper way of restarting a game? Mind you I dont say "the" proper way since I'm sure there's a hundred different ways to do this.
Also, on a separate note... If I have something such as an enemy, I keep all enemy logic contained in the class linked to the movieclip on the stage. Who should be calling add/removechild? Should I be using a factory method that takes care of all this, or should I have the engine create the enemy, and then have the enemy remove itself from stage?   Currently I'm using a mix of both, but generally I'll have a function in the engine/caller add it to stage, then have the class have an ADDED_TO_STAGE event listener. When it comes time to remove the class, I have it call it's own removeself function such as: (_container is a reference to it's container as mentioned above such as _hudContainer)
protected function removeSelf():void
    if(_container.contains(this)) {
        _container.removeChild(this);
    _container.parent.parent.dispatchEvent(new Event(Engine.START_GAME));
Thanks!

Wonderful question Travisism.
The garbage collection is strange. First I'm curious why you lump displayObjects into _gameConatiners. Does _gameConatiners get added to the stage at any point? Why not just add the proper hud at the point its required?
Anyhow. By removing listeners ,removeChild(_gameConatiners), and setting _gameConatiners=null does not mean these classes are killed. null only marks the memory locations as having no more references to them. When this occurs these objects may be removed from memory. Why do I say may, that is because it takes a specific amount of memory utilized to trigger the garbage collection.
Now just merely setting _gameConatiners=null may not ever kill your objects off. You would be required to profile this and make sure they are dieing properly. From the sounds of it you have a lot of inner children.
There is reason to believe that in some cases, when an object is removed from the main stacks that its children will be removed as well. Though, if the inner workings are so large, often the objects within referencing each other effects the way the garbace collection is stating they are still in use. Thus keeping these objects alive.
Its always best to kill off every reference being used. You can do this by ensuring each object in your movieClip class declared a kill method, and continue trickeling down each object. This ensures each object will be properly marked.
As far as your movieClips a factory method is only for the creation of objects, never for the removal.
You're best bet is to have an object that holds all objects on the stage in a collection. When you destroy the game. Itterate through this collection and remove them from the stage there.
This would fit into your engine concept. There is no reason to use a displayObject for that since its just an object. Better Yet use a Vector.<DisplayObject> to optimize this.
Back to your question is this *a* proper way to reset.
Yeah and No. The asnwer is based on the memory usage your application eats, and the amount of time to rebuild all objects. Ideally you should Pool any resources that can be reused versus having to rebuild.
For example. If you have a screen that says Game Over. why would you have to rebuild it on a reset? There is no information that was changed.   Each clip instantiation takes memory allocated and time.
Unfortunately without seeing what you have its difficult to say. But init methods are good and it can be wise to rebuild objects to being again, but as i said it depends.
Lastly, your line:
_container.parent.parent.dispatchEvent(new Event(Engine.START_GAME));
Should not have parent.parent references within. If you are creating a new Event, at least fall back on eventBubbling to allow the event to travel to the parent.parent.
You should never target parents like that in a class. Best practices is to pass in parent.parent as a reference to the class.
What if you were to add one more layer of parents to the _container. Then you would have to continue modifying parent.parent.parent. At least if you bubble the event you dont have to be concerend at all about who listens to it.

Garbage Collector and verbose GC

Hi, we are getting strange behavior with the garbage collector if the verbosegc is enabled. The gc still report it is collecting memory but none is ever freed. If the option is not enabled the problem disapear. Has anyone experience something similar?
We are running on Sun 5.8 with weblogic 5.1 sp 8 and jdk 1.2.2_09

Can you post some of the verbosegc output? Output with -XX:+PrintGCDetails might
help a little more.

Garbage Collector takes long time

Hi.
I monitored Garbage Collector log at SAP EP System and I found strange things.
Minor Garbage Collector takes 75 secs. Why It taks so long ?
Anyone have idea about that ?
We are using HP IA 64 machine and JDK 1.4.2_07.
Regards, Arnold.

Hi,
There are several SAP Notes on Java performance settings. Apply them where necessary. One of the first things to do is to use a reasonable actual Java version. As yours is _07, upgrade to a newer version.
br,
Tobas

Memory Leak / Strange Garbage Collection

Help!
We are having strange problems that appear to be related to a memory leak. The
strange part is that even if we don't hit the site, it appears to leak. Can someone
please explain the output below: Notice how freespace is decreasing, even with
no direct site activity:
[GC 48857K->35514K(130560K), 0.0136978 secs]
[GC 49018K->35548K(130560K), 0.0144821 secs]
[GC 49052K->35550K(130560K), 0.0128796 secs]
[GC 49054K->35549K(130560K), 0.0121789 secs]
[GC 49053K->35547K(130560K), 0.0126394 secs]
[GC 49051K->35582K(130560K), 0.0161642 secs]
[GC 49086K->35770K(130560K), 0.0209171 secs]
[GC 49247K->36005K(130560K), 0.0188181 secs]
[GC 49509K->36198K(130560K), 0.0129967 secs]
etc...
If I understand the numbers correctly, we have less and less free space available.
If anyone has any insights into this it will be greatly appreciated. We have problems
moving into production.
Our environment: Solaris 8, Jdk1.3.1, WL 5.1
Chris

Chris - turn off verbose GC and and don't worry about it.
Visit java.sun.com and read all about Java and Garbage Collection and JVMs.
Weblogic does 'stuff' all on it's own even when it is not being accessed - just
like your refrigerator runs when are on vacation - (please tell me you don't worry
about that too). Objects get created and deleted. There is no pressing need for
the garbage collector to recover every scrap of unused memory - so it doesn't.
When the JVM does desperately need memory, it will run a Full GC and recover (almost)
all of that.
Then again it's nice to see someone who is curious about how the darn thing works.
:) Mike
"Chris" <[email protected]> wrote:
>
Thanks for the information. I guess I didn't understand it properly.
Is there a
reason why the numbers keep increasing, even with no site activity? It
looks like
there is less and less free space every few minutes....? After running
the whole
night after posting the original message, the numbers now look like:
[GC 55586K->42276K(130560K), 0.0136978 secs]
ie. Just keeps going up. Why does it increase? Thanks for any explanations!
Dimitri Rakitine <[email protected]> wrote:
You are not 'leaking memory' (hopefully!) - these are minor collections
(quickly
copying objects which lived long enough to the old generation portion
of the heap
and reclaiming space used by objects which died young) - wait until
major collection
(when it says [Full GC ...]).
Chris <[email protected]> wrote:
Help!
We are having strange problems that appear to be related to a memoryleak. The
strange part is that even if we don't hit the site, it appears to
leak.
Can someone
please explain the output below: Notice how freespace is decreasing,even with
no direct site activity:
[GC 48857K->35514K(130560K), 0.0136978 secs]
[GC 49018K->35548K(130560K), 0.0144821 secs]
[GC 49052K->35550K(130560K), 0.0128796 secs]
[GC 49054K->35549K(130560K), 0.0121789 secs]
[GC 49053K->35547K(130560K), 0.0126394 secs]
[GC 49051K->35582K(130560K), 0.0161642 secs]
[GC 49086K->35770K(130560K), 0.0209171 secs]
[GC 49247K->36005K(130560K), 0.0188181 secs]
[GC 49509K->36198K(130560K), 0.0129967 secs]
etc...
If I understand the numbers correctly, we have less and less free
space
available.
If anyone has any insights into this it will be greatly appreciated.We have problems
moving into production.
Our environment: Solaris 8, Jdk1.3.1, WL 5.1
Chris--
Dimitri

Incremental Garbage Collector is halting my server for MINUTES at a time.

I have a Java server which services hundreds (currently 300-700 on average, target of 2000+) of simultaneous client connections, with a staggering number of long lived (but not permanent) objects.
The docs for incremental garbage collection state: "The incremental garbage collector, which is off by default, will eliminate occasional garbage-collection pauses during program execution." This is NOT true in my case. During peak load, the Server halts occasionally (once an hour or more) and entire MINUTES tick by. Average wait time is 2.5 - 3.5 minutes, the highest I have seen is 4 minutes, 10 seconds. This is entirely unnacceptable.
The server is on Red Hat Linux 6.2, kernel 2.2.14-5.0, with a gig of RAM. My current command line options are
java -server -Xincgc -Xms256M -Xmx900M
And I have just added -verbose:gc to help analyze the gc performance. I have read the gc tuning guide at http://java.sun.com/docs/hotspot/gc/index.html but still feel rather clueless about what is the optimum setup for my particular application.
I will of course start experimenting, but I was hoping to find a "wise old elf" who might give some useful pointers to accelerate the process, seeing as how the Server is already running in a production capacity, time is critical.

Are you using a Java application server like Tomcat, Dynamo, WebLogic etc. ?
In that case consider running several server instances on the machine, with the applicationserver's software load balancer. Find the amount of RAM allocated to the heap per serverinstance where garbage collection runs takes a couple of seconds, and don't allocate more than this to each server. Start as many servers as you have available RAM for.
This is the approach recommended by application server vendors such as BEA http://edocs.bea.com/wls/docs61/perform/JVMTuning.html and ATG.
A side benefit of this approach is that in case you get more concurrent users than your computer can handle, you already have the setup for spreading the load over several computers.

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]

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

How to get the garbage collector to work?

Hi,
i have i program where i load an image scale it down and save the scaled version in an array. I do this for a whole directory of images.
After every image i set the temporary variable for the loaded image = null and call the function System.gc().
My problem is, that the garbage collector does�nt give the memory of the loaded image free and the used memory of my program grows with every loaded image.
/* Reads all images from a folder an stores them in an Array of images */
     public static BufferedImage[] readScaledImagesFromFolder(String folder,
               int maxSize) {
          File dir = new File(folder);     /* Open the Folder */
          String[] children = dir.list();          /* Get the children of the folder */
          if (children == null) {
             // Either dir does not exist or is not a directory
              System.out.println("No images in the folder!");
              return null;
         } else {
              /* Init array for images */
              BufferedImage[] images = new BufferedImage[children.length];
              int i = 0;
              int index = 0;
              BufferedImage temp;
              String filename, fileending;
             for (i=0; i<children.length; i++) {
                  // Get filename of file or directory
                 filename = children;
     /* Get the fileending of the file */
     fileending = filename.toLowerCase().substring(filename.length()-4);
     if(fileending.equals(".jpg") || fileending.equals(".bmp")
               || fileending.equals(".png") || fileending.equals(".gif"))
          /* Read the image */
          temp = util.ImageUtils.loadBufferedImage(folder+"/"+filename);
          /* Scale the image down and save it in an array */
          images[index] = Util.getScaledImage(temp,maxSize);
          index++;
     temp = null;
     System.gc();
     Mosaic.sourceImageNum = index;
     System.out.println((index+1)+" resized pictures loaded from folder: "+folder);
     return images;
How can i get the gargabe collector to work after every iteration?
I tried to let the Thread.sleep(10) after System.gc() but it does�nt help.
Thank you every much
JackNeil

Hm yes.. i now that System.gc() is only a
suggestion.
But i know what my program is doing and that it
does�nt need the temporary image anymore after i have
a scaled down version. And the temporay image will become unreachable as soon as reading the next one overwrites your temp variable. Setting the variable to null doesn't have much effect.
It would be smarter to load the new image over the
old temporary image and not to expand the heapsize to
maximum.Then look at the possibitly of loading the next image into the same bufferedimage.

Garbage collector don't works.

Hello people !
When I restart the weblogic server this do not shows the lastest change that I made. I think the problem is related to the garbage collector and its bean tree.
Do you known how to solve this?
Thank you.
Regards.

I'm working with WebLogic Server 10.0 and the problem is if I restart the server this don't holds the lastest change that I made, it happens with any type of change (deploy, undeploy, create or delete servers/services, etc).
I've reviewed the log file and I've found the following error:
<Jun 2, 2008 6:45:14 PM CDT> <Warning> <Management> <BEA-141269> <The temporary bean tree updateDeploymentContext(Mon Jun 02 10:46:11 CDT 2008) was allocated for an undo, get, or activate operation, but has not been garbage collected.>
Stopping PointBase server...
PointBase server stopped.
Thank you for your attention

Clear method and Garbage Collector

Hi Gurus,
Does the Clear method (hashtable, vector etc..) is a good option for garbage collection ?
In other words, if I have a vector V with 100 elements and I perform a V.clear(), am I sure that the 100 elements are now candidates for the Garbage Collection ?
Or is it better to write a loop performing a NULL assignment for each element of the vector ?

Hi schapel,
I know it's not a good idea to force the garbage collector, but let me explain what I am confronted with.
(FYI, I didn't write the source code. Comes from a 3rd party)
The aim is to build a jsp page which is the list of the files contained in a web server directory.
I have a "Directory" class, and a "File" class. To build the jsp, each directory of the webserver is represented by a directory class, and each file, ...by a file class.
To simplify, when the tree structure of the web server is build in memory, I create a jsp page to list the files, and then, I do not need the vector anymore. But the vector can be quite huge and each client will build his own vector at the begening of his session (and will never use it again during the session).
Don't you think it's usefull in that situation to free some memory ?

Strange garbage collector behaviour

Similar Messages

Maybe you are looking for