OOM error

[Anuj Lal]

We are on solaris 9.0 32 bit

We aleady have "low"  jvm heap. We don't want to go below this.

I am pretty sure we are not running out of swap space

 

This is what we have currently

8 processes:  46 sleeping, 2 on cpu

CPU states: 95.2% idle,  3.9% user,  0.8% kernel,  0.0% iowait,  0.0%
swap

Memory: 16G real, 12G free, 3510M swap in use, 18G swap free

 

   PID USERNAME THR PRI NICE  SIZE   RES STATE    TIME    CPU COMMAND

 20139 weblogic 144  19    0 3389M 2362M cpu/2   87:19  5.16% java

 

Anuj

 

 

 

 

-----Original Message-----
From: Y Srinivas Ramakrishna [mailto:Y.S.Ramakrishna at Sun.COM] 
Sent: Tuesday, November 27, 2007 3:10 PM
To: Neo Jia
Cc: Anuj Lal; hotspot-gc-dev at openjdk.java.net
Subject: Re: OOM error

 

 

 

 

Hi Anuj --

 

> > Exception in thread "CompilerThread1" java.lang.OutOfMemoryError:
requested

> > 32756 bytes for ChunkPool::allocate. Out of swap space?

 

This is a request for 32 KB (not 32 MB as in the bug you quoted below).

 

You should probably check pmap -rs on the process. You are almost
certainly out of

C heap space (so, as you suggested below, reducing the Java heap might
help by

freeing up your apparently scarce 32-bit virtual address space to the
c-heap).

I note, though, that you have a rather modest (~2.6 GB?) heap, so on
Solaris

for example, i'd expect plenty of free address space in the sbrk
segment. What

platform are you on?

 

-- ramki.

 

> > We are already setting

> >

> > -XX:ReservedCodeCacheSize=64M

> >

> >

> >

> > As per discussion in thread

> >

> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5075468

> >

> >

> >

> > 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 is better option increasing -XX:ReservedCodeCacheSize or
decreasing

> > heap size so that we have more non heap memory available?

> >

> >

> >

> > Thanks

> >

> > ANuj

> >

> >

> >

> >

> >

> >  Jvm parameter

> >

> > with -Xms2560m  -Xmx2560m -XX:MaxPermSize=256M

> >

> > -XX:+UseConcMarkSweepGC

> >

> > -XX:+UseParNewGC

> >

> > -XX:+CMSParallelRemarkEnabled

> >

> > -XX:+UseCMSCompactAtFullCollection

> >

> > -XX:CMSFullGCsBeforeCompac

> >

> > tion=0 -XX:+HandlePromotionFailure

> >

> > -XX:CMSInitiatingOccupancyFraction=68

> >

> >  -XX:+UseCMSInitiatingOccupancyOnly -

> >

> > -XX:CMSMarkStackSize=32M

> >

> > XX:CodeCacheMinimumFreeSpace=2M

> >

> > -XX:ReservedCodeCacheSize=64M

> >

> > -XX:NewSize=512M -XX:MaxNewSize=51

> >

> > 2M -XX:MaxTenuringThreshold=6 -XX:SurvivorRatio=5
-XX:TargetSurvivorRatio=

> >

> >  -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

> > -XX:CMSMaxAbortablePrecleanTime=1

> >

> >

> >

> >

> >

> > wlstart:

> >

> > par new generation   total 449408K, used 50959K [0x46400000,
0x66400000,

> > 0x66400000)

> >

> >   eden space 374528K,   0% used [0x46400000, 0x46400000, 0x5d1c0000)

> >

> >   from space 74880K,  68% used [0x61ae0000, 0x64ca3ed0, 0x66400000)

> >

> >   to   space 74880K,   0% used [0x5d1c0000, 0x5d1c0000, 0x61ae0000)

> >

> >  concurrent mark-sweep generation total 2097152K, used 1071568K
[0x66400000,

> > 0xe6400000, 0xe6400000)

> >

> >  concurrent-mark-sweep perm gen total 211688K, used 127055K
[0xe6400000,

> > 0xf32ba000, 0xf6400000)

> >

> > }

> >

> > , 0.5049826 secs]

> >

> >

> >

> > Exception in thread "CompilerThread1" java.lang.OutOfMemoryError:
requested

> > 32756 bytes for ChunkPool::allocate. Out of swap space?

> >

> > Java Result: 1

> 

> 

> 

> -- 

> I would remember that if researchers were not ambitious

> probably today we haven't the technology we are using!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20071127/9ba9b636/attachment.htm>