Heap OOM for no apparent reason?
Raman Gupta
rocketraman at fastmail.fm
Thu Jun 2 15:35:29 UTC 2011
I did check the database but didn't find anything relevant. My search
terms may not be optimal, though I did scan through all the results
returned by "java.lang.OutOfMemoryError: Java heap space" as well as
"0K->0K".
I also suspected a bug in the collector and so I tried the same test
with the G1 collector, with the same OOM result. I didn't save the log
from the G1 test, but I can quite easily redo the test with any set of
JVM parameters that may be helpful in debugging -- the OOM seems to be
easily and consistently reproducible with this application.
Cheers,
Raman
On 06/02/2011 09:20 AM, Charles K Pepperdine wrote:
> 2011-05-27T11:35:18.214-0400: 147.823: [Full GC [PSYoungGen: 7662K->0K(72896K)] [PSOldGen: 169093K->62518K(174784K)] 176755K->62518K(247680K) [PSPermGen: 27342K->27342K(55232K)], 0.8074580 secs] [Times: user=0.29 sys=0.03, real=0.81 secs]
> UseAdaptiveSizePolicy actions to meet *** throughput goal ***
> GC overhead (%)
> Young generation: 2.65 (attempted to grow)
> Tenured generation: 0.54 (attempted to grow)
> Tenuring threshold: (attempted to decrease to balance GC costs) = 1
> 2011-05-27T11:35:19.021-0400: 148.631: [GC [PSYoungGen: 0K->0K(57856K)] 62518K->62518K(232640K), 0.0009670 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
> UseAdaptiveSizePolicy actions to meet *** throughput goal ***
> GC overhead (%)
> Young generation: 2.01 (attempted to grow)
> Tenured generation: 0.54 (no change)
> Tenuring threshold: (attempted to decrease to balance GC costs) = 1
> 2011-05-27T11:35:19.022-0400: 148.632: [Full GC [PSYoungGen: 0K->0K(57856K)] [PSOldGen: 62518K->52158K(174784K)] 62518K->52158K(232640K) [PSPermGen: 27342K->26866K(61056K)], 0.3614330 secs] [Times: user=0.32 sys=0.02, real=0.37 secs]
>
> First Full GC looks normal as PSOldGen is (174784-169093)K = 5691K from being full. Nothing happening in Perm.
> The second is where things start to get weird. I don't see why that GC was called. Stranger still, it's ~800ms *after* the full gc and yet no application thread allocated any memory out of young gen.
> for some reason that "failed" young gen collection triggers an immediate Full GC.
>
> Bug in the collector? Did you check the bug database?
>
> Regards,
> Kirk
>
More information about the hotspot-gc-dev
mailing list