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

Similar Messages

Can we explicitly stop the garbage Collector(which is running in background

Hi all,
we can clean up some memmory using System.gc() or freeMemory(). But my query is that we have to stop the gc which is running at the background in the JVM in java.
I would request u all, to help me out in solving my query.
Thanks & Regards,
Mohan

Calling System.gc() from the code is not good development practice. You shouldn't have to worry about the GC.
Are you experiencing problems? Which ones?
-Alexis

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.

How the protected finalize method is called by garbage collector

Dear All,
I have a double regarding the calling mechanism of finalize method. The access specifier of finalize method is protected, not only that if a class overrides this method then also the finalize method can be protected in the subclass of Object. But the concept of protected access specifier is, from outside of the package it can be accessed only from subclass.
The program (may be part of Garbage collector), which calls this (finalize) method mast not be in the same package (that is java.jang) nor it is a subclass of the class (whose finalize method it calls).
Then how the finalize method is getting called by the garbage collector when it is protected?
Regards,
Gourab

Refer to following link for the details
http://www.me.umn.edu/~shivane/blogs/cafefeed/2005/09/why-is-finalize-method-protected.html
The link gives answer to how a protected/private members are accessible to JVM or GC and why finalize is declared protected.

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

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

CORBA and garbage collector

Hi,
I�m writing a server with a method create(), which returns a new object supplying a home banking service for the clients.
My question is : when a given client has finished with the home banking object, do I need to call the gc, or is there an efficient one with CORBA (a kind of distributed garbage collector) ?
Thank you in advance

Maybe you heard about Distributed Garbage Collector (DGC)? Don't rely on this, since IIOP does not support this. Use PortableRemoteObject.unexportObject() to make remote objects that are no longer in use available for garbage collection.
Bert

How does the Garbage Collector handle reference-free objects?

Hi,
I am interested to know how the GC handle's objects created
without a reference.
The reason this has become of interest to me is that I have
created a "Title" class. The Title class animates each letter of
Title.text to appear in a cloud of smoke.
The smoke is a simple particle system class, when a particle
dies it removes it's associated MovieClip so that eventually all
MovieClip's have been destroyed.
Now in the Title class for each letter I do the following
(psuedo-code):
for( Title.text.length) {
CurrentLetter.twAlpha = new Tween( blah, blah, blah); //
object created
with a reference
new Smoke( CurrentLetter.x, CurrentLetter.y); // object
created
without a reference
Although this is technique is not one I would ever have
thought of in a language that doesn't use a garbage collector it is
mentioned in the Tween documentation and my class works as
intended.
The thing is although it works, it always bothers me when I
don't know precisely
why it works!
If it's working due to the short life span of the class in
question and thus simply missing the GC's window then this could be
problematic. If at some point it is still alive when the GC is
called then my class could be prematurely deleted.
Maybe a class which has a reference to an "alive" MovieClip
is immune from GC?
I Hope someone can shed some light on this topic as the GC is
something that is thinly documented to say the least!
:theory
p.s. first post!

Hi,
I would say it would be better use FREE itab at the end of the processing in your code. In the end-of-selection in your code, you can FREE all your itabs that were used in the program. This is one of the good approach of optimizing the memory.
Regards
Vimal

Automatic Garbage collector after JVM almost hit max value on weblogic ?

Hi All,
I have application on weblogic 10MP2. I use 4G JVM. My application getting slow when the usage of JVM hit arround 70-80% of max heap size. Unfortunatelly, the garbage collector didn't run when it hit that high. So to keep my application in good state, I need to MANUALLY hit the Perform GC to keep the JVM below 70%.
Is there any settings to tell the JVM to perform GC when the free space of the JVM hit 30%?
What will the weblogic do if one of the server in warning state? There is a settings in the weblogic to specify when it hit some percentage of free space, it will bring the server to warning state. Will it do the Garbage Collector?
Need your help on this. I am tired of hitting the Perform GC button.
Really appeciate your help.
Thanks,
Eric

I am replying to my own post because I found a tool that
helped me solve in two hours what I had been stumped on
for the past few days.
The Heap Analysis Tool.
I had a major memory leak problem. I couldn't locate
the source until I downloaded and used this tool(for free).
This tool keeps track of memory used by objects,
each objects references, objects references by each
object, and all objects instances. All of this information
can be obtained in html format for efficient traversing
of object chains. I would highly recommend looking
this tool over if you intend on doing memory intensive
programming.
In case your curious where my error was I had two problems
which are now fixed. One. I had a couple of BufferedImages
that were leaking 30MB RAM. Two. I didn't know that using
ObjectStream's to read/write objects stored references
to the objects being written(preventing garbage collection).
Deffinately worth running the Heap Analysis Tool before
pointing a finger at System.gc().

Understanding garbage collector output

Hi all.
My application uses an increasing amount of memory, and in order to solve the problem I have turned on the -verbosegc option. The output is as follows:
<GC: managing allocation failure: need 1040 bytes, type=1, action=1>
<GC: 504 milliseconds since last GC>
<GC: freed 6530 objects, 288432 bytes in 10 ms, 35% free (661616/1887424)>
<GC: init&scan: 1 ms, scan handles: 7 ms, sweep: 2 ms, compact: 0 ms>
<GC: 4 register-marked objects, 7 stack-marked objects>
<GC: 8 register-marked handles, 136 stack-marked handles>
<GC: refs: soft 0 (age >= 32), weak 0, final 1, phantom 0>
<GC: managing allocation failure: need 1040 bytes, type=1, action=2>
<GC: 10 milliseconds since last GC>
<GC: expanded object space by 1048576 to 2936000 bytes, 58% free>
<GC: need to expand mark bits to cover 2560 bytes>Is any one able to explain this output for me? My problem is that the object space is expanded regularly and eventually the garbage collector writes "totally out of heap space" and an OutOfMemoryError occurs.
My -version is
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition
Classic VM (build 1.3.0-1, native threads, jit)running on UNIX, Digital Alpha.
Regards,
Torben Lange

Just a follow up on my memory leak problem which I have solved now.
I had created a class which handles database connections. The constructor looked something like this:
Connection connection;
public DBConnection() {
DriverManager.registerdriver(new myDriver());
connection = DriverManager.getConnection(...);
}My application creates an object of this class, uses it and then closes the object. This goes on all the time. (Yes, it could be handled another way by pooling database access or simply keep the connection open without closing it - but it isn't.)
It seems that the registration of the driver in the constructor eventually will fill the memory - apparently the same driver is registered several times.
Problem was solved when changing the code into the following:Connection connection;
static boolean isRegistered = false;
public DBConnection() {
if (! isRegistered) {
DriverManager.registerdriver(new myDriver());
isRegistered = true;
connection = DriverManager.getConnection(...);
}Hope this could help others in the same situation.
Regards,
Torben Poort Lange

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( 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 periodic rate

Hello!
In an application which I'm studying, garbage collector (opportunely configured with command line options) run on a configurable periodic time: this means that every (10 minutes for example) I call method System.gc() in my code.
If I don't explicitily call this method, Java virtual machine will intervene by itself?
Will it intervene only when a threshold amonut of memory is consumed (too many JAVA object instantiated which wait for be freed) ?
Thank you very much in advance
Diego

Does anyone knows what's the difference with Full GC
and why it intervenes ? Because you told it to. You called System.gc().
I don't think that was the question you meant. My guess is you wanted to know why the Concurrent Low Pause Garbage Collector intervened?
Off that first link I gave you was an link to an article that describes the GC output log ( http://java.sun.com/docs/hotspot/gc1.4.2/example.html ). If you read that article it describes what each of the values in the gc output means.
From that article:
[GC [<collector>: <starting occupancy1> -> <ending occupancy1>, <pause time1> secs] <starting occupancy3> -> <ending occupancy3>, <pause time3> secs]
where
<collector> is an internal name for the collector used in the minor collection
<starting occupancy1> is the occupancy of the young generation before the collection
<ending occupancy1> is the occupancy of the young generation after the collection
<pause time1> is the pause time in seconds for the minor collection.
<starting occupancy3> is the occupancy of the entire heap before the collection
<ending occupancy3> is the occupancy of the entire heap after the collection
<pause time3> is the pause time for the entire garbage collection. This would include the time for a major collection is one was done.
The reason the Concurrent Mark Sweep(CMS) starts is also in the first link I gave you. When the Concurrent Garbage Collector thinks you are about to run out of heap it starts the CMS.
1234.306: [GC [1 CMS-initial-mark: 342810K(499712K)] 342906K(524224K), 0.0026879 secs]In your case that was when the used heap reached 342810K out of a current allocated heap of 499712K
You could describe the specific problem you are investigating. Also it would be helpful if you provided the VM parameters you have for starting your application.

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

Hi all,
How does a garbage collector knows, when it should deallocate the memory of an
object ?. And How can we make ready an object to deallocate it's memory by garbage collector ?.

Hi all, Hi!
How does a garbage collector knows, when it
should deallocate the memory of an
object ?.Objects are kept in a memory heap, and the objects that are having references are called dirty objects, and objects with no references are called clean objects(I think so, don't believe me).
clean objects (and objects with weak references) are liable for garbage collection.
there are certain thresold conditions (which I don't know), when they are reached, gc runs.
These thresold conditions are jvm specific(jvm optimization), one could be when jvm feels it is going to get out of memory(again, don't believe me). You would have to go into details of jvm for that(I don't want to go there as I have lots of other things to learn).
And How can we make ready an object
to deallocate it's memory by garbage collector ?.there is no way you can control gc mechanism manually, because jvm have to take care of a lots of optimizations. so you can't predict when your object will be collected by gc.
(that's why people don't beleave on finalize method).

Garbage Collector - which one?

Similar Messages

Maybe you are looking for