GCOverheadLimit does not work ?

[David Tavoularis]

Hi Jon,

I would like to understand the computation of the percentage for the following Full GC example :

57587.994: [Full GC [PSYoungGen: 262144K->260978K(317184K)] [PSOldGen: 1310719K->1310719K(1310720K)] 1572863K->1571698K(1627904K) [PSPermGen: 17242K->17242K(20480K)]
Heap after GC :
PSYoungGen      total 317184K, used 260978K (eden=262144K, from=OK (out of 55040K))
PSOldGen        total 1310720K, used 1310719K
PSPermGen       total 20480K, used 17242K

So the percentage is computed like this : ((317184K-260978K)+(1310720K-1310719K)+(20480K-17242K))/(317184K+1310720K+20480K)=59445K/1648384K=3.6% > 2%

The fix would be to compute it like this : ((262144K-260978K)+(1310720K-1310719K)+(20480K-17242K))/(317184K+1310720K+20480K)=4405K/1648384K=0.3% < 2%



Is there a WA to this issue ?

1. Is is possible to change by property the percentage from 2% to 5% ?

2. Maybe I could reduce the young size from 256MB to 128MB, and it will automatically reduce (?) the survivor from 55040K to 27520K ? And the percentage would be in this case 1.9% and the OOM would be triggered.


Thanks in advance for your explanations

-- 
David

On Mon, 09 Jun 2008 18:08:27 +0200, Jon Masamitsu <Jon.Masamitsu at Sun.COM> wrote:

> David,
>
> There is a bug somewhere here that relates to the GCOverheadLimit.
> I think the problem is that the survivor spaces are not being
> used and the survivor space is large enough so that the
> calculation of the amount of free space in the heap is > 2%.
> The survivor spaces are not being used because only full
> collections are being done later in the run and the survivor
> spaces are used for minor (young generation) collections.  Though
> the description of the GCOverheadLimit refers to  the amount
> of the heap collected, it really should just say that amount of
> free space in the heap.  That's a bug in the specification for
> the parameter.  I'm not sure that an out-of-memory should
> be thrown if there is 2% of the heap free - that's in keeping
> with trying to minimize the false positives resulting from this
> feature.
>
> Jon
>
> David Tavoularis wrote:
>> Hi,
>>
>> It seems that the mechanism GCOverheadLimit did not trigger, even if more than 98% of the total time is spent in garbage collection and less than 2% of the heap is recovered. The process spent 3 hours in this state, performing Full GC after Full GC.
>>
>> I am using Parallel Collector on Java6u4/Solaris9. Is it a bug or maybe I do not understand this feature ?
>>
>> "TimeStamp","GC duration","Duration between 2 FullGC"
>> 57356.444	27.46	27.471
>> 57383.915	27.14	27.137
>> 57411.052	27.63	27.738
>> 57438.79	33.72	33.724
>> 57472.514	30.07	30.087
>> 57502.601	27.84	27.842
>> 57530.443	28.46	28.519
>> 57558.962	29.03	29.032
>> 57587.994	29.31	29.321
>>
>> Full GC logs are available at http://people.via.ecp.fr/~tony/tmp/gc_200802282216.zip
>>
>> Thanks in advance
>>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>