Plantage de la JVM

Bonjour,

J'ai l'erreur suivante après un long traitement qui nécessite beaucoup de mémoire. Peut-être faut-il faire des réglages fins au niveau du garbage collector mais je ne m'y connais pas trop.

[error occured during error reporting]
#
# 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_04-b05 mixed mode)
#
# Error ID: 434F44452255464645520E435050005E 01
#
# Problematic Thread:
Unexpected Signal : 11 occurred at PC=0xFE180F00
Function=[Unknown. Nearest: JVM_IsInterface+0x8E28]
Library=/usr/j2sdk1_4_2_04/jre/lib/sparc/server/libjvm.so

Current Java thread:
prio=5 tid=0x000f3458 nid=0xb runnable
#

Heap at VM Abort:

Dynamic libraries:
Heap
def new generation 0x10000 /usr/j2sdk1_4_2_04/bin/java
total 302848K, used 288788K0xff360000 /usr/lib/libthread.so.1
[0x99400000, 0xac4b0000, 0xae950000)
0xff3a0000 /usr/lib/libdl.so.1
eden0xff200000 /usr/lib/libc.so.1
0xff340000 /usr/platform/SUNW,Sun-Fire-880/lib/libc_psr.so.1
0xfe000000 /usr/j2sdk1_4_2_04/jre/lib/sparc/server/libjvm.so
0xff2e0000 /usr/lib/libCrun.so.1
0xff1e0000 /usr/lib/libsocket.so.1
0xff100000 /usr/lib/libnsl.so.1
0xff0d0000 /usr/lib/libm.so.1
0xff1c0000 /usr/lib/libsched.so.1
0xff310000 /usr/lib/libw.so.1
0xff0a0000 /usr/lib/libmp.so.2
0xff070000 /usr/j2sdk1_4_2_04/jre/lib/sparc/native_threads/libhpi.so
0xfe7d0000 /usr/j2sdk1_4_2_04/jre/lib/sparc/libverify.so
0xfe790000 /usr/j2sdk1_4_2_04/jre/lib/sparc/libjava.so
0xff020000 /usr/j2sdk1_4_2_04/jre/lib/sparc/libzip.so
0xfddc0000 /usr/j2sdk1_4_2_04/jre/lib/sparc/libnet.so

Heap at VM Abort:
Heap
def new generation total 302848K, used 288788K [0x99400000, 0xac4b0000, 0xae950000)
eden space 293696K, 98% used space 293696K, 98% used [0x99400000, 0xaadde128, 0xab2d0000)
[0x99400000, 0xaadde128, 0xab2d0000)
from from space 9152K, 1% used space 9152K, 1% used [0xab2d0000, 0xab2f7118, 0xabbc0000)
to [0xab2d0000, 0xab2f7118, 0xabbc0000)
space 9152K, 0% used to [0xabbc0000, 0xabbc0000, 0xac4b0000)
space 9152K, 0% used [0xabbc0000, 0xabbc0000, 0xac4b0000)
tenured generation tenured generation total 623872K, used 338247K total 623872K, used 338247K [0xae950000, 0xd4a90000, 0xd9400000)
[0xae950000, 0xd4a90000, 0xd9400000)
the the space 623872K, 54% used space 623872K, 54% used [0xae950000, 0xc33a1cb8, 0xc33a1e00, 0xd4a90000)
[0xae950000, 0xc33a1cb8, 0xc33a1e00, 0xd4a90000)
compacting perm gen total 162816K, used 162750K [0xd9400000, 0xe3300000, 0xf9400000)
the space 162816K, 99% used [0xd9400000, 0xe32ef838, 0xe32efa00, 0xe3300000)

compacting perm gen Local Time = Fri Mar 21 17:13:43 2008
total 162816K, used 162750KElapsed Time = 691718
[0xd9400000, 0xe3300000, 0xf9400000)
the space 162816K, 99% used [0xd9400000, 0xe32ef838, 0xe32efa00, 0xe3300000)
#
# HotSpot Virtual Machine Error : 11
# Error ID : 4F530E43505002EF 01
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Java VM: Java HotSpot(TM) Server VM (1.4.2_04-b05 mixed mode)
#
# An error report file has been saved as hs_err_pid21747.log.
# Please refer to the file for further information.
#

Salut,
Salut,
Essaye d'allouer plus de mémoire en lançant le programme avec la commande java -Xmx256m TonProgramme (i.e. 256 Mo sont alloués).

J'ai déjà modifié ce paramètre, on alloue 1024 Mo voire 2048 et le problème arrive quand même.

Dans ce cas tu peux utiliser un profiler et voir ce qui consomme tant de mémoire . Tu dois avoir un problème quelque part ...

Un profiler ? Y a-t-il une doc là dessus quelque part sur le site ?
J'utilise Jboss Rules et je "compile" une matrice très grande. J'espère que c'est notre utlilisation qui a un problème et non pas la librairie car je ne pourrai pas m'en sortir sinon.

mmmm, délicat. Il me semble que JBoss Rules génère du bytecode à la volée pour la matérialisation des règles. De grande chance que le problème trouve son origine là.

Effectivement, il créé des classes et des méthodes correspondant au contenu des matrices. De quel côté devrais-je m'orienter ? Paramètres du Gc ou Jboss Rules ?

Pour les profiler tu as des plugins pour Eclipse, un tout intégré dans NetBeans et sinon des solutions propriétaires. Tu peux toutefois les utiliser en version demos.

Je ne connais pas Jboss Rules mais au moins tu verras si le problème de consommation vient de là ou de ton code (à supposer qu'il y ait une partie de code développée par toi ?).

Sinon pour le garbage collector, bien souvent, il s'agit d'y aller un peu à tatons et voir ce qui marche ou pas. T'es en multithread, sur solaris, en 64 bits ... ?? bref y'a pleins de points à prendre en compte si tu veux tuner ton gb ... :?

tu peux aussi utiliser JConsole intégré dans la JVM pour suivre la conso mémoire et les actions du garbage collector, ça peut au moins te donner quelques pistes ...

Oui oui, il existe une sur-couche que nous avons développé et qui est peut-être la source du problème. Je vais voir pour Jconsole, merci