Home.... | log in.... | Pub my question! | Sign-up....

Java-index >> Desktop >> Runtime Environment

"CompilerThread0" java.lang.OutOfMemoryError: Chunk::new. Out of swap space

We are running JBoss 4.0.4 on Java 1.5.0_08 on Windows XP.

The VM is running with these params :

-server

-Xrs

-Xms512M

-Xmx512M

-Xss128K

-Xdebug

-Xrunjdwp:transport=dt_socket,address=10570,server=y,suspend=n

-Xloggc:"C:\temp\servergc.log"

-XX:+ShowMessageBoxOnError

After running for 2 days the VM crashes with following error:

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

The GC log when it crashes looks like :

177324.150: [GC 122420K->76129K(518464K), 0.0175989 secs]

177327.682: [GC 122721K->75616K(518464K), 0.0237069 secs]

177333.104: [GC 122208K->75228K(518464K), 0.0551933 secs]

Heap memory wise it seems ok.

The memory pool a few minutes before the crash look like :

Total Memory Pools: 5

Pool: Code Cache (Non-heap memory)

Peak Usage : init:2359296, used:36118784, committed:36569088, max:50331648

Current Usage : init:2359296, used:35988544, committed:36569088, max:50331648

Pool: Eden Space (Heap memory)

Peak Usage : init:47710208, used:47710208, committed:47710208, max:47710208

Current Usage : init:47710208, used:39487176, committed:47710208, max:47710208

Pool: Survivor Space (Heap memory)

Peak Usage : init:5963776, used:5963776, committed:5963776, max:5963776

Current Usage : init:5963776, used:1607208, committed:5963776, max:5963776

Pool: Tenured Gen (Heap memory)

Peak Usage : init:477233152, used:102377280, committed:477233152, max:477233152

Current Usage : init:477233152, used:74919856, committed:477233152, max:477233152

Pool: Perm Gen (Non-heap memory)

Peak Usage : init:16777216, used:47667280, committed:47710208, max:67108864

Current Usage : init:16777216, used:47115768, committed:47185920, max:67108864

How can we avoid/workaround this issue?

Thanks.

[1994 byte] By [kogs11a] at [2007-10-3 7:27:01]

«« hashtable problem please help
»» JAVA 2 RUNTIME ENVIRONMENT

# 1

Might try increasing the Virtual Memory setting in Windows (Under My Computer / Advanced / Performance options), although if the heap size is good then this may not help.

i_program_java_all_daya at 2007-7-15 2:25:56 >

top of Java-index,Desktop,Runtime Environment...

# 2

The problem is that once Xmx is set to lets say 512M, I would expect the java server process size to be 512M + Y = 750M in the windows task manager.

And maybe oscillate around that value.

But what we are is seeing is the VM size for the process in the Windows Task Manager (Or Committed Virtual Memory in the JConsole summary tab) just keeps growing 1.3 ~ 1.7 Gig and eventually run into the swap space issue.

All this while our heap memory just oscillates well below the bounds of the Xmx setting. The heap memory graph is almost a straight line.

How can a java process with an Xmx setting of 512M get to 1.5G in VM size?

Thanks You Very much.

kogs11a at 2007-7-15 2:25:56 >

top of Java-index,Desktop,Runtime Environment...

# 3

How can a java process with an Xmx setting of 512M get to 1.5G in VM size?

Ugh - that means your JRE (without the heap) is taking up over 1GB. Should not be happening, I agree. First, I would check your app for any native components or JNI code that might be memory-leaking. If so, maybe try commenting them out and see if you get same behavior. If no native components, maybe try running the app under an older point release of the JRE (_04, _06), or maybe even 1.4 if the code is backward-compilable with 1.4. This is just to see if maybe a leak was introduced into the JRE. Not sure where to go from there, maybe trying a tool like JProbe or Netbeans Profiler to see if it gives reports the same heap information (probably will). Good luck, let us know how it goes.

i_program_java_all_daya at 2007-7-15 2:25:56 >

top of Java-index,Desktop,Runtime Environment...

# 4

One possibility is finalizable objects that allocate native (c-heap) memory. Your old generation is fairly empty, so it may not have been collected for some time, allowing a number of finalizable objects to accumulate. If finalizable objects are in the old gen, they will not be reclaimed until the old gen is collected, which only happens when the old gen becomes full or when you call System.gc().

One way to check for this is to add the option -XX:+PrintClassHistogram to the command line and run java from a terminal or command prompt window. After memory usage has grown, hit ctrl-break on the keyboard (ctrl-\ on Unix) and the VM will print a histogram-like summary of the number of instances of each type. Look for 'Finalizer' in the list. Here's some sample output:

num#instances#bytes class name

--

1:54772217527104 java.lang.ref.Finalizer

2:5477118763376 waste_of_time

3:4268410320 <no name>

If it does turn out to be finalizable objects, then try to avoid creating lots and lots of them: either reuse objects if possible, or use weak references instead of finalization. See the following article for more info:

http://www.devx.com/Java/Article/30192

If the above aren't possible, then (cough, gag) you can call System.gc() and System.runFinalization() periodically. But this should be the very last resort, and can easily result in performance problems.

jxca at 2007-7-15 2:25:56 >

top of Java-index,Desktop,Runtime Environment...

Desktop New Topic

Desktop Hot Topic