Bug ID: JDK-4916142 CompilerThread0: OutOfMemoryError Chunk::new Out of swap space?

Type: Bug
Component: hotspot
Sub-Component: runtime
Affected Version: 1.4.2

Priority: P2
Status: Closed
Resolution: Duplicate
OS: windows_2000
CPU: x86

Submitted: 2003-09-02
Updated: 2003-11-03
Resolved: 2003-11-03

Sybase has reported the foll error logged by Sun JRE version 1.4.1.x and 1.4.2 
while running SPECj2001 benchmark in EAServer 5.0 on Windows 2000. The crash 
occurs within a couple of minutes of starting the test. The machine is setup 
with 1GB RAM and additional 2.2GB of virtual space.

I have tried following options but none helped.

1. Changing min and max heap sizes (from 368M to 968M).
2. Tried JVM version 1.4.1_01, 1.4.1_03, and 1.4.2_01. Also tried server and 
client HotSpot VMs for these versions.
3. Tried most applicable gc tuning parameters.
  * NewSize (300M), MaxNewSize(300M)
  * SurvivorRatio=2,20
  * +AggressiveHeap, +UseTLAB
  * +UseParallelGC
  * MaxPermSize (128M)
  * CompileThreshold=500,5000,20000,50000 using hotspot server VM

Starting services...
Accepting connections.
Done binding to all configured Name Servers.
[GC
 245759K->24935K(858112K)
, 0.4225403 secs]
[GC
 270693K->29964K(858112K)
, 0.3689858 secs]
[GC
 275724K->32110K(858112K)
, 0.2452689 secs]
[GC
 277870K->32798K(858112K)
, 0.1830918 secs]
[GC
 278558K->33400K(858112K)
, 0.2089325 secs]
[GC
 279160K->38075K(858112K)
, 0.8158809 secs]

Exception 
in thread "
CompilerThread0
" 
java.lang.OutOfMemoryError: requested 
602368
 bytes
 for 
Chunk::new
. Out of swap space?

JNI_Utils::VMAbortHook(): 
#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Server VM (1.4.2_01-b06 mixed mode)
#
# Error ID: 4A41564123414C4C530E4350500016
#
# Problematic Thread: 
prio=5 tid=0x06133438 
nid=0xfcc 
runnable 

#

Heap at VM Abort:

Heap
 def new generation  
 total 276480K, used 52942K
 [0x1f8e0000, 0x324e0000, 0x324e0000)
  eden
 space 245760K,  13% used
 [0x1f8e0000, 0x219236e8, 0x2e8e0000)
  from
 space 30720K,  64% used
 [0x2e8e0000, 0x2fc50488, 0x306e0000)
  to  
 space 30720K,   0% used
 [0x306e0000, 0x306e0000, 0x324e0000)
 tenured generation  
 total 581632K, used 18170K
 [0x324e0000, 0x55ce0000, 0x55ce0000)
   the
 space 581632K,   3% used
 [0x324e0000, 0x3369e858, 0x3369ea00, 0x55ce0000)
 compacting perm gen 
 total 16384K, used 10500K
 [0x55ce0000, 0x56ce0000, 0x59ce0000)
   the
 space 16384K,  64% used
 [0x55ce0000, 0x567213b0, 0x56721400, 0x56ce0000)
JNI_Utils::VMAbortHook(): 


If JIT is disabled, the problem does not occur but performance is not 
acceptable. Also, if I run at a lower load, problem does not occur. 


I tried increasing the MaxPermSize set to 128M but still got the
failure. We do end up loading lot of classes (roughly 1500 or so)
during the benchmark run. We also observed the JVM's GC activity using
"jvmstat" tool at 500 ms interval. The permsize never exceeded 15M.

WORK AROUND -XX:+UseDefaultStackSize -Xss256K ###@###.### 2003-11-03

03-11-2003

EVALUATION This doesn't look like a GC bug. That may explain why it doesn't go away when you tweak the GC parameters. The actual error is from a CompilerThread. The error id decodes to "javaCalls.cpp, 22". I asked Mike Paleczny about the compiler thread, but he said he didn't think that the compiler thread ever calls JavaCallWrapper::JavaCallWrapper, which is where that line is from. But, if that's true, why is there a guarantee there: guarantee(!thread->is_Compiler_thread(),....) to trip over? A stack trace would be really helpful. Would the submitter please add one to the bug? Thanks. Now that I look at it again, I wonder if the CompilerThread didn't detect the allocation failure and then try to call JNI_Utils::VMAbortHook(), which might have tried to call out to Java code. ###@###.### 2003-09-03 ---------------------------------------------------------------- ###@###.### 2003-09-09: The customer's tests have revealed the following re the C heap exhaustion problem: . the error (C heap exhaustion) happens with both c1 and c2; the application runs to completion with -Xint . it is independent of the garbage collector used . it appears not to be related to finalization or reference object processing. -Xint runs to completion without exhausting C heap, even if we run with -XX:-RegisterFinalizers or -XX:-RegisterReferences I am changing the sub-category to runtime_system since this appears unrelated to GC. Prasad has attached the memory dump stats (vadump) on the process, but we have not looked at that to see if that will shde any light on the problem. The runtime engineer who evaluates this should look at the vadump output available as an attachment to this bug report. --------------------------------------------------------------- Customer (Sybase) no longer sees the reported problem with the workaround -XX:+UseDefaultStackSize -Xss256K, developed to fix bug #4765019, caused due to 2GB limitation for user programs on Windows and 1MB default stack size. Sybase is happy with this workaround and has confirmed closure of escalation associated with this bug. Since this issue has been resolved for customer using workaround developed to fix bug #4765019, I am closing this bug as duplicate of #4765019. ###@###.### 2003-11-03

03-11-2003

Duplicate :	JDK-4765019 - unable to create more than 2300 threads
Relates :	JDK-4899343 - CMS collector: prompter finalization?