About Garbage Collector

In Java, there is one system call for garbage collector.
System.gc();
I want to know the significance of this system call for GC. Even after calling this method, garbage collector won't get started, still it will run on its own time.
If this is the thing then what's the significance of this method call?
Please let me know this.
Thanking you,
Ketan

Addendum
In a heavy data application, for instance, that stores records in memory for some purpose, then releases that memory and creates next set of records in memory, calling gc really help.
We have such application where in we tested its performance with and without calling gc. No wonder, we found better results by calling gc.

Similar Messages

Porblem about Garbage Collectors of OID

Hi,
I'm wondering if garbage collectors will clear up the data of ODS_CHG_LOG table. For my testing environment, there're nealy 800 operations/sec.During 5-day running, the size of OLTS_DEFAULT tablespace is beyond 32G, and will reduce the system's performance. I set up iAS 10.1.2.0.2 by default. Do garbage collectors take effect?
Regards,
Bill

Hi,
I'm wondering if garbage collectors will clear up the data of ODS_CHG_LOG table. For my testing environment, there're nealy 800 operations/sec.During 5-day running, the size of OLTS_DEFAULT tablespace is beyond 32G, and will reduce the system's performance. I set up iAS 10.1.2.0.2 by default. Do garbage collectors take effect?
Regards,
Bill

Idea about garbage collector

Hi,
I'm working in finance area and there are a lot of talks about latency last years though I never saw system that had guaranteed GC STW spikes < 2 ms
so my question why its not possible to implement smart pointer GC (like in C++) so every reference assignment would increment counter in object
and every reference removing decrement - this would add additional cost but 99 % of objects can be safely collected concurrently - sure it does not deal with circular dependencies but I suppose on some applications it would be just great so it can be used with CMS GC

It's certainly possible to use "smart pointers" to implement reference counting garbage collection. It's just that no one has figured out how to make it performant. Yet. All the counter updates have to be atomic, which hurts performance and scalability on multi-processor boxes. There are schemes to avoid the atomic counter updates, for example for pointer stores to thread stacks, but they start to get really complicated and hard to debug. How much of a performance hit are you willing to take to eliminate the stop-the-world pauses?
As you say, you still need something global to clean up cycles.
<2ms is a fairly stringent target for stop-the-world pauses, but not unthinkable. "Guaranteeing" those pauses is unthinkable, without some limitiations on what you do with your heap. You should work with your Oracle support engineers to tune your collector settings. Or post your GC logs and likely someone can come up with ideas to reduce your pause times.

Garbage collector tuning. Permanent generation

Hi all,
I'm learning about garbage collector tuning.
Why my system always gives for the permanent generation 8192K?
And why is always full with 8191K? Maybe it is full because my application manages an internal java cache but ....
Does it is OK that is always full?, how can I change its size?
[Perm : 8191K->8191K(8192K)], 0.1922860 secs]
I'm using Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
Linux SuSE
I'm using the following command
java -XX:+PrintGCDetails -XX:NewRatio=3 -Xss256k -Xms128m -Xmx256m
[Full GC [Tenured: 0K->2206K(98304K), 0.1920700 secs] 24643K->2206K(127808K), [Perm : 8191K->8191K(8192K)], 0.1922860 secs]
[GC [DefNew: 26299K->1168K(29568K), 0.0566740 secs] 28505K->3374K(127872K), 0.0567870 secs]
[GC [DefNew: 27472K->3264K(29568K), 0.0391920 secs] 29678K->6757K(127872K), 0.0392870 secs]
[GC [DefNew: 29567K->3264K(29568K), 0.0756940 secs] 33061K->12212K(127872K), 0.0757840 secs]
Thaks,

Hi!
In the permanent generation you have data like class information and static strings. This data is usually never garbage-collected since it never becomes garbage anyway (it is "permanent data"). Per default, the JVM starts with a very small perm gen (somewhere around 4 MB, I believe, but this may be system specific). The default max size for the perm gen is 64 MB on most systems.
If your application needs more space in the perm gen than initially allocated, the JVM will enlarge the perm gen until your data fits into the perm gen (or the max size is reached). In your case your applications seems to need 8 MB perm space, therefore the JVM enlarges the perm gen until it is 8 MB large.
So, to answer your question, it's totally ok that your perm gen is 8 MB large and always full. There is no need to change its size in your case. If you still want to do it, you can use -XX:PermSize=<initalSize> and -XX:MaxPermSize=<maxSize>. Setting -XX:PermSize=8m may speed up your application start a little since the JVM allocates enough space right in the beginning and doesn't need to enlarge the perm gen afterwards.
Nick.

* How about flash play 8 Garbage Collector working?

Hi, I need to add some Image controls dynamically, yes,the
number of those are unpredictable.
My code to create them like this:
quote:
public function addImg(name:String, x:Number, y:Number):void
var sm1:Image = new Image();
sm1.source = "imgs/down_medium.gif";
sm1.name = name;
sm1.x = x;
sm1.y = y;
this.addChild(sm1);
Then, it appeared in my application. if I add numbers of
Image in my stage, they eat my memory crazily.
so I want to kill some Image which is not in use, but I
crashed.
An Image named "img4kill" in stage, it's index in
this.getChildren() is4, and it holds a image which size is about
230K.
I tried to kill it like this:
quote:
this.removeChildAt(4);
yes, it's remove from the stage in faith, but I watched the
memory that the browser using, before and after killing it.
I found the memory it takes is not released.
How can I kill it from both the stage and memory ? I tried
the global function "delete" ,but failed too.
I know that flash play 8.5 and later use a powerfull
GC(garbage collector), but in the sample above, it dose't work for
me.
who can save me from this mud layer?any ideas?
thanks a lot .
(sorry about my ugly english)
[email protected]

Don't worry, the garbage collector will work very well in this case (and in every other case too :) ). It will only collect an object when no more references are pointing to it. Your array still holds a reference to all the items it contains (unless you explicitly do array[index] = null).
There are only three ways that I know of to destroy a reference to an Object: 1). Set the reference to null 2). Let the reference fall out of scope 3) reassign the reference to another object
The garbage collector will also be able to collect objects that have a cyclical references as long as none of the objects in the cycle are reachable.
It pays to understand the ins and outs of garbage collection and memory management in the VM. Knowing that will let you know, for example, that allocating an Object in Java is a very cheap operation (while it is pretty expensive in C/C++).
Check http://www.ibm.com/developerworks/java/library/j-jtp10283/ and http://www.ibm.com/developerworks/java/library/j-jtp11253/ and for more details about the GC
Also don't worry about the performance impact of setters and getters, either the javac compiler or the Virtual Machines Just In Time Compiler will inline those small methods.
In short don't worry about such low level performance problems and concentrate on your coding style and algorithms. The Hotspot JVM is an amazingly efficient piece of software. It also include a lot of optimizations that work very well in optimizing "standard" code. The more normally you code, the faster your program will be, so don't try clever optimizations tricks, they probably won't work well in java.
Read the following articles for some discussion about performance in Java:
http://www.ibm.com/developerworks/java/library/j-jtp04223.html
http://www.ibm.com/developerworks/java/library/j-jtp09275.html
http://www.ibm.com/developerworks/java/library/j-jtp01274.html

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]

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

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.

How intelligent is the garbage collector?

Hi all,
I've got a question about how garbage collection works in an ABAP objects context.
If there are no more references an object is cleaned up and the memory released. Fine.
What about an object O1, which in turn creates another object O2. O2 however also contains a refernce to O1.
When the original process completes, this leaves two objects that reference each other, but with no other contact to the 'outside world'. Is the garbage collector intelligent enough to dump them?
Any input appreciated,
Cheers
Mike

Hi,
Thanks for the feedback. I am still not sure - you say 'when the program ends it's part'. This is exactly the point - when the program ends, do the objects remain because they still contain references to each other?
More detail:
The references are public instance attributes of both objects (different classes). I would prefer to use functional methods, but am stuck with public attributes which I'm populating in the constructor.
So a process P declares a local var LV_O1 and does a CREATE OBJECT LV_O1.
In the constructor of O1, it does a
CREATE OBJECT me->ATTR_O2 to populate it's attribute with a reference to an instance of O2.
O2 doesn't need to do a CREATE OBJECT, but assigns a ref to O1 to it's attribute ATTR_O1.
So now O1 and O2 refer to each other by public attributes:
O1->ATTR_O2 and O2->ATTR_O1.
The big question is what happens when process P ends and it's variable LV_O1 ceases to exist?
In case anyone's wondering about the overall wisdom of the design, they have to be public attributes (used in Workflow) and they have to refer to each other as instantiation may also happen the other way around.
Cheers
Mike

Are there any types of Garbage Collector ??

are there any types of Garbage Collector ??

AmitChalwade123456 wrote:
kajbj wrote:
AmitChalwade123456 wrote:
this question was asked to me in interview !! I could not answer thatI doubt that they asked you the question that you first posted, because the answer would be yes.
Did they ask you what different types of garbage collectors that are implemented in the VM?That mean there are types of GC !! can u give some info about themThe answer to that depends on what VM you are talking about, and what version of VM you are talking about. E.g. an IBM VM isn't implemented in the same way as a Sun VM, and a Sun 1.3 VM has other algorithms than an 1.5 VM.

Inefficient garbage collector process - WLS 8.1 SP6 - JVM jdk142_13 (SUN)

Hi all,
I am trying to perform some tuning operations in my server (maestroServer_01) because the application uses the total amount of heap size and the garbage collector process is not running fine. The arguments used on this VM are:
-server -Xms2048m -Xmx2048m -Xss512k -XX:PermSize=384m -XX:MaxPermSize=384m -XX:+UseParallelGC -XX:ParallelGCThreads=4 -XX:+UseAdaptiveSizePolicy -XX:NewRatio=8 -XX:SurvivorRatio=12 -Xverify:none -Xnoclassgc -XX:+DisableExplicitGC -XX:+PrintGCDetails -Dweblogic.webservice.i18n.charset=utf-8 -Duser.timezone=$JAVA_TZ -DejbURL='t3://localhost:9081' -DjpdURL='http://localhost:9081'
Please let me know if I can change these parameters in the WLS:
Services -> Bridge -> Messaging Bridge Thread Pool Size -> from 5 to 20
Configuration -> Tuning -> Socket Readers -> from 33 to 60, and disable "Enable Native IO" option.
I got some informations from internet about some parameters that can be used to improve the memory utilization of this JVM. The parameters are described in the link below:
http://java.sun.com/performance/reference/whitepapers/tuning.html
Does anyone know what can be done? The WLS needs to be restarted every day!
Thanks!

yes regularely .. :-) (as you can see from the posts..)
to your problem, the connectstring seems perfectly valid for a oracle light db installation (which we install within the bpel installation)
can you check if this polite process is running?
HTH clemens

Logging Garbage collector for an OC4J with 2JVM

Hi, I have one OC4J with two JVM setted.
If I put -verbose:gc it logs in the std Output file.
I trying to log the garbage collector in two different file each one for one JVM.
Anyone as an idea?

Don't create massive amounts garbage memory. It's that simple. You should try to limit the creation of memory inside your animation loop. If there is a process inside the loop that creates memory, there is definitely some way to create that item staticly, rather than allocating new memory with each iteration. There shouldn't be any kind of problem that would involve the creation of THIS much memory, and it's deallocation. If you read about how the garbage collector is implemented, you'll notice that it stores all of it's memory on a single conveyor belt. This is for ALL memory in the program. Therefor once the garbage collector has gone through and marked all of the memory that needs to be reclaimed, it performs it's sweep and must feeze the entire program because that conveyor belt can not be manipulated while it's re-arranging the memory. The garbage collector will eliminate MOST memory leaks, but it does not eliminate any thought on the part of the programmer about memory.
-Jason Thomas.

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

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.

About Garbage Collector

Similar Messages

Maybe you are looking for