VM Error - heap memory problem

[Surendra Singhi]

Hi,
I am using Java on a windows xp machine. Recently while writing a
program which takes large amount of memory I ran into this runtime
error. And it is giving me nightmares, as I have a very important
deadline to meet.
The program takes large amount of memory so I tried increasing the heap
size and set the following options for the vm
-verbosegc -ms128m -mx128m
Also, at one or two places I am explicitly calling gc, to help free up
some memory. The time the program will take to execute is not a concern
as long as it runs smoothly.

Attached is a part of the trace of the gc run and the run time error.

How to fix this bug? And is it memory allocation which is causing it?

Any help on this will be heartily appreciated.
Thanks in advance.

--
Surendra Singhi

www.public.asu.edu/~sksinghi/


[GC 14246K->6146K(130112K), 0.0047735 secs]
[GC 14273K->6473K(130112K), 0.0017715 secs]
[Full GC 9045K->6183K(130112K), 0.0460307 secs]
[GC 14310K->6221K(130112K), 0.0022045 secs]
[GC 14349K->6206K(130112K), 0.0014379 secs]
[GC 14333K->6222K(130112K), 0.0006643 secs]
[GC 14350K->6206K(130112K), 0.0005355 secs]
[GC 14334K->6209K(130112K), 0.0005559 secs]
[GC 14337K->6212K(130112K), 0.0006160 secs]
[GC 14339K->6215K(130112K), 0.0019924 secs]
[GC 14343K->6218K(130112K), 0.0006233 secs]
[GC 14346K->6232K(130112K), 0.0021648 secs]
[GC 14360K->6229K(130112K), 0.0007012 secs]
[Full GC 6988K->6229K(130112K), 0.0446780 secs]
#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_06-b03 mixed mode)
#
# Error ID: 43113F2652414D452D41503F491418160E435050005C
#
# Problematic Thread: prio=5 tid=0x0035f020 nid=0x358 runnable
#

Heap at VM Abort:
Heap
def new generation total 9088K, used 2794K [0x10010000, 0x109e0000,
0x109e0000)
eden space 8128K, 34% used [0x10010000, 0x102cab28, 0x10800000)
from space 960K, 0% used [0x10800000, 0x10800000, 0x108f0000)
to space 960K, 0% used [0x108f0000, 0x108f0000, 0x109e0000)
tenured generation total 121024K, used 6229K [0x109e0000,
0x18010000, 0x18010000)
the space 121024K, 5% used [0x109e0000, 0x10ff5628, 0x10ff5800,
0x18010000)
compacting perm gen total 4096K, used 2159K [0x18010000, 0x18410000,
0x1c010000)
the space 4096K, 52% used [0x18010000, 0x1822bcc8, 0x1822be00,
0x18410000)

 

[asaguden]

You are not setting the JVm memory correctly.
Memory settings are a part of the -X settings

Further, this is not an expert opinion only my own:
- I would recommend against doing your own gc too increase
performance,
the jvm does that better than you. However you can hint to the jvm
what kind of gc
you need. (see links)

I would do this:
1. Increase heap size to make the application work
2. Check with som kind of analyzing tool what eats up your memory,
and check to see whether the architecture can be less memory
consuming.
3. Give correct jvm/hotspot parameters to maximise performance for
this particular
application (see links)

Hotspot performance:
http://java.sun.com/docs/hotspot/gc1.4.2/

JVM options:
[http://java.sun.com/docs/hotspot/VMOptions.html]

Good luck.
asaguden

 

[John C. Bollinger]

Hi,
I am using Java on a windows xp machine. Recently while writing a
program which takes large amount of memory I ran into this runtime
error. And it is giving me nightmares, as I have a very important
deadline to meet.
The program takes large amount of memory so I tried increasing the heap
size and set the following options for the vm
-verbosegc -ms128m -mx128m

Your limits there aren't really that big. On the other hand, the GC
output you posted doesn't show your program coming anywhere near using
it all.

Also, at one or two places I am explicitly calling gc, to help free up
some memory.

That should never be necessary. It is also unlikely to be related to
your problem.

The time the program will take to execute is not a concern
as long as it runs smoothly.

Attached is a part of the trace of the gc run and the run time error.

Snipped automatically by my newsreader because you put it in your
signature. In any case, the VM is reporting an internal error. This
most likely indicates one of: a bug in the VM, corrupted VM or class
files (system or user), or some kind of unrecoverable error in native
code. I would try the application on a different system first,
preferably the cleanest one you can find.

How to fix this bug? And is it memory allocation which is causing it?

The bug is unlikely to be caused by Java memory allocation -- if Java
cannot allocate enough memory then it throws an OutOfMemoryError. If
you're doing any JNI then I would look there first for a bug. It is
possible that there is no bug in your code. Do note that the error
message asks you to report the incident as a VM bug, although it might
be a bit hasty to do that without verifying that you can duplicate it in
a clean environment.


John Bollinger
(e-mail address removed)

 

[JML]

Hi,
besides increasing the heap memory (this is a temporal solution), you should
use profiler software to search the memory leaks in your app. Maybe you
allocate many needless objects in the heap memory, with a profiler you can
see the live instances of each created object in a determinated moment.

 

[Jeff]

Hi,
I am using Java on a windows xp machine. Recently while writing a program
which takes large amount of memory I ran into this runtime error. And it
is giving me nightmares, as I have a very important deadline to meet.
The program takes large amount of memory so I tried increasing the heap
size and set the following options for the vm
-verbosegc -ms128m -mx128m
Also, at one or two places I am explicitly calling gc, to help free up
some memory. The time the program will take to execute is not a concern as
long as it runs smoothly.

Attached is a part of the trace of the gc run and the run time error.

How to fix this bug? And is it memory allocation which is causing it?

Any help on this will be heartily appreciated.
Thanks in advance.

--
Surendra Singhi

www.public.asu.edu/~sksinghi/


[GC 14246K->6146K(130112K), 0.0047735 secs]
[GC 14273K->6473K(130112K), 0.0017715 secs]
[Full GC 9045K->6183K(130112K), 0.0460307 secs]
[GC 14310K->6221K(130112K), 0.0022045 secs]
[GC 14349K->6206K(130112K), 0.0014379 secs]
[GC 14333K->6222K(130112K), 0.0006643 secs]
[GC 14350K->6206K(130112K), 0.0005355 secs]
[GC 14334K->6209K(130112K), 0.0005559 secs]
[GC 14337K->6212K(130112K), 0.0006160 secs]
[GC 14339K->6215K(130112K), 0.0019924 secs]
[GC 14343K->6218K(130112K), 0.0006233 secs]
[GC 14346K->6232K(130112K), 0.0021648 secs]
[GC 14360K->6229K(130112K), 0.0007012 secs]
[Full GC 6988K->6229K(130112K), 0.0446780 secs]
#
# HotSpot Virtual Machine Error, Internal Error
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_06-b03 mixed mode)
#
# Error ID: 43113F2652414D452D41503F491418160E435050005C
#
# Problematic Thread: prio=5 tid=0x0035f020 nid=0x358 runnable
#

Heap at VM Abort:
Heap
def new generation total 9088K, used 2794K [0x10010000, 0x109e0000,
0x109e0000)
eden space 8128K, 34% used [0x10010000, 0x102cab28, 0x10800000)
from space 960K, 0% used [0x10800000, 0x10800000, 0x108f0000)
to space 960K, 0% used [0x108f0000, 0x108f0000, 0x109e0000)
tenured generation total 121024K, used 6229K [0x109e0000, 0x18010000,
0x18010000)
the space 121024K, 5% used [0x109e0000, 0x10ff5628, 0x10ff5800,
0x18010000)
compacting perm gen total 4096K, used 2159K [0x18010000, 0x18410000,
0x1c010000)
the space 4096K, 52% used [0x18010000, 0x1822bcc8, 0x1822be00,
0x18410000)

Setting Xmx can limit the size of the heap which you don't want to do. I
set Xms240m and don't set Xmx. The heap starts big and can grow.

Profiling to find the memory leaks is the sustainable solution.

 

[Surendra Singhi]

Your limits there aren't really that big. On the other hand, the GC
output you posted doesn't show your program coming anywhere near using
it all.



That should never be necessary. It is also unlikely to be related to
your problem.



Snipped automatically by my newsreader because you put it in your
signature. In any case, the VM is reporting an internal error. This
most likely indicates one of: a bug in the VM, corrupted VM or class
files (system or user), or some kind of unrecoverable error in native
code. I would try the application on a different system first,
preferably the cleanest one you can find.



The bug is unlikely to be caused by Java memory allocation -- if Java
cannot allocate enough memory then it throws an OutOfMemoryError. If
you're doing any JNI then I would look there first for a bug. It is
possible that there is no bug in your code. Do note that the error
message asks you to report the incident as a VM bug, although it might
be a bit hasty to do that without verifying that you can duplicate it in
a clean environment.


John Bollinger
(e-mail address removed)

Thanks for all your answers.
I reported this bug to Sun and I got the following response:

"Thank you for using our bug submit page. The bug you have reported
appears to be a duplicate of the Bug ID: 5009717. For more information
on this, please refer to this bug at:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5009717
"

There was no problem with the code, it was an incompatibility issue
between code compiled in different version of jvm(i.e. 1.4.05) and being
run using a newer version of jvm(1.4.06).

 

[Bjorn Borud]

[Surendra Singhi <[email protected]>]
|
| There was no problem with the code, it was an incompatibility issue
| between code compiled in different version of jvm(i.e. 1.4.05) and
| being run using a newer version of jvm(1.4.06).

good thing you found the source of the problem.


although your problem was an actual bug and not GC tuning, I thought
I'd share a tip with you about GC tuning anyway .

if it were heap sizing issues I would recommend installing and running
jvmstat. this is the single most useful tool I've seen for
understanding what is going on with your application vs GC and heap
parameter tuning. follow the advice in the docs and start tweaking
the coarse-grained parameters first.

I had a heap sizing problem which was quickly resolved by just looking
at the jvmstat GUI (visualgc) while the program was running and
adjusting some parameters.

also: nothing good will come from running GC manually. check your
heap with jvmstat and tune if necessary. most of the time you just
need to size things correctly. sometimes you *might* want to choose a
different GC algorithm (but most of the time you should leave this
untouched).

if someone says you should run GC manually, you can safely ignore
them.


some links:

http://java.sun.com/performance/jvmstat/
http://www.unixville.com/~moazam/stories/2004/05/18/visualizingGarbageCollection.html

-Bjørn