OOM error

[steve goldman]

Anuj Lal wrote:
> Jdk version
> 
> 1.5.0_13
> 
> Exception in thread "CompilerThread1" java.lang.OutOfMemoryError:
> requested 32756 bytes for ChunkPool::allocate. Out of swap space?
> 
> Java Result: 1
> 
>  
> 
> We are already setting 
> 
> -XX:ReservedCodeCacheSize=64M
> 
>  
> 
> As per discussion in thread
> 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5075468

This bug is assigned to me. I visited the customer for several days and 
they were never able to reproduce it. In the case of the customer the 
piece of code being compiled was a very large jsp. If you've ever looked 
at the code for a jsp you might understand why a compiler might barf. :-)

The setting of ReservedCodeCacheSize is either total serendipity or 
complete bs. The memory we are running out of this instance is not the 
code cache or for that matter the java heap. Since the java heap is not 
involved the gc list is actually not that appropriate for this bug. (The 
jvm has gotten much better of time trying to make it clear what kind of 
memory is actually exhausted.)

> 
>  
> 
> I am sure we have enough heap as well as swap space available.
> 
>  
> 
> I am wondering above bug is fixed for 1.5.13?

What you see is a symptom. Many different bugs can exhibit this symptom. 
This bug isn't as bad a say 4951689 
(http://blogs.sun.com/fatcatair/entry/least_favorite_bug) but it is 
definitely a catch-all place especially for the compilers. Certainly the 
original bug reported by the customer was not fixed since they never 
reproduced or produced a core dump.

> 
> What is better option increasing -XX:ReservedCodeCacheSize or decreasing
> heap size so that we have more non heap memory available?

You know my feelings about ReservedCodeCacheSize. The best thing to do 
would be to try and get a core dump that I can look at. The next best 
would be a stack trace at the point of failure as that could well be a 
big enough clue.


-- 
Steve