customer is experiencing problems with incgc after about 3-4 hours of run time.

All GC log files are in /net/cores.east/cores/36898396

The problem is that incremental GC's stop at a certain point and only full GC's then happen.

[GCDesired survivor size 8388608 bytes, new threshold 1 (max 32)- age 1: 9585200 bytes, 9585200 total- age 2: 11096 bytes, 9596296 total- age 3: 5080 bytes, 9601376 total- age 4: 26280 bytes, 9627656 total- age 5: 9104 bytes, 9636760 total- age 6: 4280 bytes, 9641040 total- age 7: 3920 bytes, 9644960 total- age 8: 4520 bytes, 9649480 total- age 9: 6400 bytes, 9655880 total- age 10: 4736 bytes, 9660616 total- age 11: 3840 bytes, 9664456 total- age 12: 3776 bytes, 9668232 total- age 13: 4520 bytes, 9672752 total 655957K->632642K(695040K)11114.92,632642,655957,695040,49152,trainscavenge, 124.8486986 secs]
<Timestamp Wed Dec 17 17:27:20 CET 2003 (1071678440055)>
[Full GC 665410K->625667K(686720K)11316.62,625667,665410,686720,49152,old generation too full to scavenge, 193.4307353 secs]
<Timestamp Wed Dec 17 17:30:41 CET 2003 (1071678641885)>
<Timestamp Wed Dec 17 17:31:41 CET 2003 (1071678701898)>
[Full GC 1008588K->626639K(756096K)11607.68,626639,1008588,756096,49152,train generation full, 191.6687819 secs]
<Timestamp Wed Dec 17 17:35:32 CET 2003 (1071678932819)>
[Full GC 651504K->624895K(686976K)11774.97,624895,651504,686976,49152,old generation too full to scavenge, 157.5444063 secs]
<Timestamp Wed Dec 17 17:38:20 CET 2003 (1071679100181)>
[GCDesired survivor size 8388608 bytes, new threshold 1 (max 32)- age 1: 10669072 bytes, 10669072 total 647905K->625698K(687104K)11882.75,625698,647905,687104,49152,trainscavenge, 100.1594606 secs]
<Timestamp Wed Dec 17 17:40:07 CET 2003 (1071679207916)>
[Full GC 658466K->620529K(680320K)12113.38,620529,658466,680320,49152,old generation too full to scavenge, 214.1621132 secs]


This causes severe performance issues effecting this customer's customers.

The java flags are:
java -client -XX:NewSize=64m -XX:MaxNewSize=64m -XX:SurvivorRatio=2 -XX:MaxPermSize=128m -XX:SoftRefLRUPolicyMSPerMB=0 -Xconcurrentio -Xincgc -verbosegc -XX:+PrintGC -XX:+PrintHeapUsageOverTime -XX:+PrintTenuringDistribution -Xms512m -Xmx1024m
-XX:SoftRefLRUPolicyMSPerMB=0 was used for a test to see if this may be related to a soft ref bug that was fixed in 1.4.2, but customer still saw the same problem.

questions such as
how can the old generattion be full? the settings of the jvm are mx 1024m;
newsize and maxnewsize 64m; maxpermsize 128m. Thus approx. 830 m should be
available for the old generation, which is significantly higher than the 670m
total size at which this behaviour occurs. And why is the total heap size
reduced if there is not sufficient space for the old generation?
I'm not sure I'm reading the numbers correctly here and thus my confusion......

[Full GC
675738K->619819K(674496K)17707.75,619819,675738,674496,49152,old
generation too full to scavenge, 152.0622748 secs]
###@###.### 11/5/04 01:34 GMT