Filling the survivor space is part of the GC collection process, not the result of new objects being created. My understanding is that a minor collection with the default collector involves copying to the "target" survivor space, the "live" objects in Eden and the other survivor space, maybe except for objects old enough to go to the "tenured" space. The old non-target survivor space and Eden are then set to "empty" since they no longer contain "live" objects. This is how the garbage gets released.
The assumption is that old survivor space and especially Eden will be mostly filled with "dead" objects and there won't be so many "live" objects that they overflow the target survivor space. If the target survivor space overflows, then I think that GC has no choice but to start putting them into the "tenured" space, making them uncollectible until the next full GC. Its occurance implies that, the GC time goes up because it is keeping a lot of temporary- but-not-dead-yet objects. I think with the times you seeing that there may be more involved than just poor GC performance. To do this with just GC, I would think it would require extremely high numbers of small temporary objects. I have seen code inefficient enough to do this, but it typically requires some effort to abuse garbage collection to this degree. Cheers, Larry > -----Original Message----- > From: Akash Jauhar [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 23, 2004 3:58 PM > To: Tomcat Users List > Subject: RE: tomcat 3.3.1 takes a high time for Minor GC > > > Larry > > Thanks for the note. A few questions > A) my understanding of GC makes me think that no garbage can be > generated when young generation is being collected. As mentioned that > for young generation we use the default stop the world collector. When > that happens all other application threads stop. Hence no > garbage can be > generated. Can you explain why do you think that more garbage can be > created (to fill the survivor space). Is my understanding of stop the > world garbage collector incorrect > > Thanks for letting me know > > Akash Jauhar > Sapient > > YIM: akashjauhar > AIM: akashjauhar > e-mail: [EMAIL PROTECTED] > > > > -----Original Message----- > From: Larry Isaacs [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 23, 2004 12:39 PM > To: Tomcat Users List > Subject: RE: tomcat 3.3.1 takes a high time for Minor GC > > > I'm not a GC expert, so please note that the following > speculation is based upon memories of some GC document I > read a while back. I vaguely recall that GC performance > drops if the survivor space fills up while collecting the > young generation. I think the result is that what might > have been short-lived objects instead get pushed into the > tenured generation because they weren't short-lived enough. > > From your log output I note that about the "231968" mark, the > time between GCs drops dramatically. Evidentially the rate > of garbage generation has substantially increased. I believe > if the rate is too high, temporary objects get "tenured" for > the reason stated above. Handling these "tenured temporary" > objects adds to the GC time. Even more so if they are small > and lots of them. > > It may help to try to determine what has caused the generation > of garbage to increase so much. If a culprit is found, reducing > the amount of garbage is the best way to improve performance. > If that isn't possible, then GC tuning may be your only > alternative. > > I'm not aware of anything in Tomcat 3.3.1 that would account > for such garbage generation. One of Tomcat 3.3.x's strengths > over Tomcat 3.2.x is the reduced garbage generation from the > overhead of handling requests. > > I have experienced the pleasure of watching Optimizeit show me > how a JSP page, via some support classes, was creating ~3.7Gb > of StringBuffer/String/char[] data. This made finding what to > fix much easier. I don't know in your case if you will need a > profiler to get a good picture of where the garbage is coming > from. > > HTH. > > Cheers, > Larry > > > -----Original Message----- > > From: Akash Jauhar [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, March 23, 2004 12:53 PM > > To: Tomcat Users List > > Subject: tomcat 3.3.1 takes a high time for Minor GC > > > > > > Hi All > > > > Cisco CNAMS application runs on the following platform > > OS: Solaris 9 > > Webserver: Apache 1.3.27 > > JDK: JDK 1.4.2 build 28 > > Servlet Engine: tomcat 3.3.1a > > > > We are noticing some weird GC behaviour when the tomcat does > > Minor GC. I > > am pasting some garbage collection logs below > > > > 231867.984: [GC 231867.985: [DefNew: 127232K->3840K(127232K), > > 0.1125831 > > secs] 288818K->170206K(350384K), 0.1128485 secs] > > 231946.970: [GC 231946.970: [DefNew: 127232K->3840K(127232K), > > 0.1348222 > > secs] 293598K->177196K(350384K), 0.1350464 secs] > > 231968.052: [GC 231968.052: [DefNew: 127232K->3840K(127232K), > > 0.1818662 > > secs] 300588K->182066K(350384K), 0.1821628 secs] > > 231969.314: [GC 231969.315: [DefNew: 127232K->3543K(127232K), > > 16.4172505 > > secs] 305458K->185389K(350384K), 16.4175191 secs] > > 231987.248: [GC 231987.248: [DefNew: 126935K->3840K(127232K), > > 10.7419554 > > secs] 308781K->189356K(350384K), 10.7422411 secs] > > 231999.225: [GC 231999.225: [DefNew: 127232K->3840K(127232K), > > 16.1320322 > > secs] 312748K->196413K(350384K), 16.1323798 secs] > > 232015.949: [GC 232015.950: [DefNew: 127232K->3840K(127232K), > > 42.2998381 > > secs] 319805K->201339K(350384K), 42.3001041 secs] > > 232058.781: [GC 232058.781: [DefNew: 127232K->3840K(127232K), > > 146.5896470 secs] 324731K->206361K(350384K), 146.5898922 secs] > > 232206.831: [GC 232206.832: [DefNew: 127232K->3840K(127232K), > > 110.7859999 secs] 329753K->211019K(350384K), 110.7862726 secs] > > 232318.209: [GC 232318.209: [DefNew: 127232K->3840K(127232K), > > 68.5541489 > > secs] 334411K->215994K(350384K), 68.5544029 secs] > > 232387.893: [GC 232387.893: [DefNew: 127232K->3840K(127232K), > > 126.8755081 secs] 339386K->221793K(350384K), 126.8757738 secs] > > 232515.276: [GC 232515.276: [DefNew: 127232K->3840K(127232K), > > 139.7813258 secs]232655.058: [Tenured: 223686K->154822K(223792K), > > 278.7132327 secs] 345201K->154822K(351024K), 418.4964431 secs] > > 232934.349: [GC 232934.349: [DefNew: 123392K->3840K(127232K), > > 164.3069723 secs] 278214K->163782K(385272K), 164.3072616 secs] > > 233099.848: [GC 233099.848: [DefNew: 127232K->3840K(127232K), > > 91.4000872 > > secs] 287174K->169894K(385272K), 91.4005897 secs] > > 233191.652: [GC 233191.652: [DefNew: 127232K->3840K(127232K), > > 204.1755072 secs] 293286K->176929K(385272K), 204.1757747 secs] > > 233396.272: [GC 233396.272: [DefNew: 127232K->3840K(127232K), > > 101.8621946 secs] 300321K->183426K(385272K), 101.8624498 secs] > > > > > > Note how the minor collection takes high GC times > > (highlighted in bold). > > It takes as high as 204 seconds. We are using the default > GC algo both > > for the old generation and the young generation(which happens > > to be stop > > the world collector for young generation and mark - compact > collector > > for the old generation). Our heap size when the tomcat starts > > is bounded > > by 256 MB on the lower side to 778 MB on the higher side. > > > > I am unable to understand what would cause tomcat to do GC > for such a > > long time esp in the young generation. what is even more > wierd is that > > the time between consecutive GC for young generation is > > almost equal to > > time for which the GC happened . what would cause the young > generation > > to fill so quickly. > > > > Anyone has any ideas what is going on ? > > > > -Akash > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
