Discussion :

[LGnord]

Comme mon titre l'indique, j'ai un problème de PermGen.

Malheureusement, la majorité des informations que je trouve lie cette erreur au déploiement multiple d'une application. Or ce n'est pas mon cas.

Par contre, j'ai trouvé un petite définition:
La zone perm définit une zone de mémoire qui accueille les objets permanents.
Il n'y a pas de collectes dans cette zone.

Cela veut-il dire que la valeur des champs statiques est stockée dans cette zone?

En effet, j'ai une grosse structure statique dans mon code qui pourrait être à l'origine du OutOfMemoryError.

Merci de votre aide.

[kimz]

Salut,
Si c'est sous Eclipse que tu travailles, je pense que le problème de PermGen a été fixé sous la nouvelle version 3.3.1.1
Pour savoir ce qui est à l'origine de du OutOfMemory regarde le plugin TPTP
si ça peut aider ..

[LGnord]

Merci de ton aide.

Oui, je suis sous eclipse. Malheureusement je ne peux pas utiliser eclipse 3.3.1 (j'utilise un plug-in qui ne fonctionne que sous 3.2). Je ne peut donc pas tester ta proposition. De plus, je ne vois pas le rapport entre eclipse et PermGen. C'est plutôt un problème de JVM?

Je vais regarder le plugin TPTP. J'utilise aussi jprofiler4 mais, pour l'instant, il ne m'a pas fourni d'éléments utiles.

[jhaythem]

essaye d executer avec plus de memoire alors et puis essaye de chercher ou viens ta fuite -Xmx256.

[djo.mos]

Bonjour.
Tout d'abord, le PermGen Space est spécifique aux JVMs de Sun.
Ensuite, cet espace sert à stocker tout ce qui est realtif aux classes (et pas aux objets), ce qui inclut entre autres leurs structures (méthodes, champs, annotations, etc. qui peuvent servir à l'instantiations d'objets ou encore à la reflection), les champs static, les chaines littérales, etc. bref, tout ce qui ne serait pas garbage collected ...
Il est possible d'augmenter la taille du PermGenSpace sur les JVMs Sun avec l'option:

-XX:MaxPermSize=256m

qui le met à 256Mo par exemple.
Il faisait 64Mo avant, et je crois que dans la JRE 6 update 3 on l'a augmenté à 128Mo.

Bonne chance.

[LGnord]

Merci beaucoup djo.mos.

J'ai essayé d'augmenter la taille de mon PermGen. Je ne fait que repousser le problème. De plus, je me vois mal expliquer à mes clients qu'il faut ajouter une option lorsqu'ils utilisent mon programme.

Savoir que les champs statiques sont stockés là va m'aider. Je vais essayer de réduire leur taille et leur contenu. Comme je le disais au-dessus, j'ai des faiblesses de ce coté là.

> le PermGen Space est spécifique aux JVMs de Sun.
C'est la première fois que je vois cette information. Il est donc inutile que je continue à chercher dans la spec de la JVM. Je vais plutôt aller voir sur le site de sun.

[djo.mos]

Bonjour.
Simple curiosité, tu utilises une librairie qui fait de l'instrumentation du bytecode ? genre cglib ou asm ? Car ce genre de libs est un casse-gueule assuré pour la PermGen ...

[M@th]

Salut,

Tu as aussi le paramètre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

-XX:PermSize=256m

Mais il me semble que ces paramètres ne sont pas spécifiques à Sun enfin bref... Tu peux toujours faire un peu d'optimisation sur la gestion de la mémoire dans ton application !

Tu fournis comment ton application à tes clients ? Personnellement, j'ai travaillé sur l'optimisation de la mémoire pour un projet dans ma boîte et on a légèrement modifié ces paramètres chez le client également pour que ça se passe bien !

Bonne journée,
Mathieu

[LGnord]

On livre à nos clients des plugins eclipse.

[LGnord]

Pour instrumenter le bytecode, on utilise bcel.
En quoi est-ce un casse-gueule? Comment l'éviter?

Pour être sur d'avoir compris:
Si j'écris:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
private static GrosType field = new  GrosType();
{
    field = new  GrosType();
}

La première instance de GrosType() est stockée dans le PermGen mais n'est jamais garbage collecté?

[djo.mos]

Les libs d'instrumentation de bytecode modifient la structure des classes, qui est stocké dans le PermGenSpace à chaque modification d'une classe, ça consomme de l'espace d'où son saturation.

Ton bout de code m'a l'air un peu bizarre: Tu instancies le champ static à chaque création d'une instance ... ce ne serait pas plutôt :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
private static GrosType field = new GrosType();
static {
  field = new GrosType();
}

[LGnord]

D'accord. Ce n'est pas lié à une librairie en particulier.

[Duc Lebowski]

ce ne serait pas plutôt :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
private static GrosType field = new GrosType();
static {
  field = new GrosType();
}

Autant faire seulement celà dans ce cas là :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
private static GrosType field = new GrosType();

[LGnord]

Oui mon code n'est pas très crédible.

La question est : j'ai un champ statique qui initialisé plusieurs fois. Toutes ses valeurs sont-elles stockées indéfiniment dans le permGem?

Tu dis que les champs statics sont stockés dans cette zone. Est-ce sa déclaration ou sa valeur?

Encore merci pour ton aide.

[LGnord]

J'ai commenté le code qui instrumente le bytecode.
Tout va beaucoup mieux.

J'ai donc compris l'origine de mon problème. En grande partie grace à vous, car je ne serais jamais partie sur cette piste.

Par contre, je n'ai aucune idée de la solution mais là je vais devoir me debrouillé tout seul.

[LGnord]

Pour clore le sujet, quelques liens utiles:

Explications claires sur perm gen:
http://www.eclipsezone.com/eclipse/forums/t77021.html

Eclipse bug #92250 -- Un bug sur la taille du perm gen.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=92250

FAQ : Augmenter la taille du perm gen.
http://wiki.eclipse.org/FAQ_How_do_I..._to_Eclipse%3F