Strange isssue about OOM

Tue Jan 15 23:31:59 PST 2008

Dear all,

Do anybody uderstand the triggering reason of GC and Full GC.
Confused by 

1 The [Young] less used when call GC.

25213.699: [GC 25213.699: [DefNew: 756K->82K(169600K), 0.0078670
secs]25213.707: [Tenured[Unloading class
sun.reflect.GeneratedConstructorAccessor274]
: 226997K->221430K(349568K), 2.0173917 secs] 227753K->221430K(519168K),
2.0254397 secs].

2 Frequenty full GC

27980.476: [GC 27980.476: [DefNew: 51783K->327K(169600K), 0.0179721
secs]27980.494: [Tenured: 223693K->220424K(349568K), 1.2211616 secs]
275476K->220424K(519168K), 1.2393261 secs]
27981.715: [Full GC 27981.715: [Tenured: 220424K->220413K(349568K),
1.2103792 secs] 220424K->220413K(519168K), [Perm :
27498K->27498K(65536K)], 1.2105386 secs]
Total time for which application threads were stopped: 2.4509644 seconds
Application time: 32.3719363 seconds
28015.299: [GC 28015.299: [DefNew: 18543K->164K(169600K), 0.0073310
secs]28015.306: [Tenured: 220413K->220577K(349568K), 1.2056721 secs]
238957K->220577K(519168K), 1.2131937 secs]
28016.512: [Full GC 28016.512: [Tenured: 220577K->220252K(349568K),
1.2023572 secs] 220577K->220252K(519168K), [Perm :
27499K->27498K(65536K)], 1.2025188 secs]
Total time for which application threads were stopped: 2.4167372 seconds

Thanks & Regards
Chris Guan
Tel: 24056255

-----Original Message-----
From: Y Srinivas Ramakrishna [mailto:Y.S.Ramakrishna at Sun.COM] 
Sent: Wednesday, January 16, 2008 3:20 AM
To: CHRIS GUAN (ISDC-ISD-OOCLL/SHA)
Cc: hotspot-gc-use at openjdk.java.net
Subject: Re: RE: Strange isssue about OOM

Hi Chris --

> Thanks for your help.
> 
> Java version "1.4.2_13";
> Oracle Application Server Containers for J2EE 10g (10.1.2.2.0) ; No 
> System.gc(); WebService;
> 
> Would you please explain "HandlePromotionFailure"?Where to see CR 
> 6206427.
> 

In older versions of the JVM (such as the one you are using), we didn't
have a mechanism to recover from a partial scavenge if the scavenge
could not be completed because of lack of sufficient space in the old
generation to promote tenured objects into. So we used to be very
conservative in starting a scavenge and probably conservative in
precipitating a full collection if we felt the next scavenge would not
succeed. This conservatism could cause us to waste free space in the old
generation. See for example:-

http://java.sun.com/docs/hotspot/gc1.4.2/#4.4.2.%20Young%20Generation%20
Guarantee|outline

In later JVM's, we added the ability to recover from a partially
completed scavenge and to compact the entire heap. This allowed us to be
less pessimistic about going into a scavenge, and would waste less space
in the old generation even when you run with large young generations.
See:-

http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html#0.0.0.0.%20Young
%20Generation%20Guarantee%7Coutline

I'd actually recommend upgrading to a more recent JVM where you'd see
performance improvements, but if that is not possible, then with
1.4.2_13, you should use -XX:+HandlePromotionFailure which should allow
you to make more efficient use of the heap by avoiding the issue
described above.

As to the question of why you need to do, for example, the following
scavenge :-

> > 25313.039: [GC 25313.039: [DefNew: 2421K->91K(169600K), 0.0079322
> > secs]25313.047: [Tenured: 220264K->220182K(349568K), 1.3464051 secs]

My only guess is that the application may be requesting the allocation
of a large object. But that's a guess. (Yes, we should ideally have that
information be available from the gc logs.)

-- ramki

IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is not intended for you, please delete it immediately unread.  The internet cannot guarantee that this communication is free of viruses, interception or interference and anyone who communicates with us by email is taken to accept the risks in doing so.  Without limitation, OOCL and its affiliates accept no liability whatsoever and howsoever arising in connection with the use of this email.  Under no circumstances shall this email constitute a binding agreement to carry or for provision of carriage services by OOCL, which is subject to the availability of carrier's equipment and vessels and the terms and conditions of OOCL's standard bill of lading which is also available at http://www.oocl.com.