OOM error

[Y Srinivas Ramakrishna]

pmap -rs will tell you what's taking up address space. It could be, for example,
that you have lots of threads (so the space is gone to thread stacks, so you might
try -Xss<...> or it could be that you have loaded lots of native libraries that have
taken up address space, or it could be that you have lots of file descriptors or
sockets or mmapped files or other native resources that are tying up your
address space).

(the reference to "swap space" in the message is usuallysomewhat misleading;
i think there are plans to fix that message to be smarter / less misleading).

-- ramki

> 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!
>