Discussion :

[DaveRidic]

Bonjour à tous,

je travail sur une application de dessin en Java/Swing qui permet, entre autres, d'exporter en PDF (grâce à iText) le canevas réalisé. Mais j'ai des difficultés à gérer efficacement ma mémoire.

Déjà, voilà ce que je comprends de la mémoire. Arrêtez-moi si je me trompe. Pour chaque zone de la mémoire (Eden and Tenured) il y a :

• La mémoire utilisée (used) réellement consommée par la JVM ;
• La mémoire réservée (comitted) elle est extensible et empiète au besoin sur la partie "virtual". C'est la mémoire que semble voir le gestionnaire de tâches sous windows par exemple ;
• La mémoire maximale (max) pouvant être utilisée. Au délà => Java Heap Space error :-)

Le problème que je rencontre concerne la mémoire réservée "committed" parce qu'elle s'étend si j'en besoin, mais ne se réduit pas quand on je n'en ai plus besoin.

En temps normal mon application consomme peu de mémoire, mais ponctuellement lors de l'export en PDF, la mémoire réservé peut atteindre 300 ou 400Mo et ne redescend pas une fois l'action terminée, bien que la mémoire utilisée (used) retombe à moins de 10Mo :



Ce qui fait que, dans le gestionnaire de tâches de Windows, mon appli commence à 10Mo de RAM et se termine à 450Mo... Pas terrible !

Savez-vous comment gérer la mémoire de manière à ce que la partie réservée de l'Eden ou du Tenured s'étende et se réduise en fonction des besoins de l'appli ?

De manière général, c'est un topic de discussion sur la gestion et l'optimisation de la mémoire avec Java.

Merci de vos avis éclairés

[wax78]

Pour avoir il y'a 1 mois jouer avec iText pour generer des PDF, je px dire que je montait parfois a 750Mega juste pour generer le PDF... apres je ne comprends pas vraiment ta question en fait. Une fois que tu as generé ton PDF en theorie, la mémoire devrait redescendre ou au moins pouvoir reservir).

[DaveRidic]

Bah théoriquement oui, elle devrait redescendre. D'ailleurs la mémoire utilisée redescend, mais la mémoire réservée augmente et ne redescend pas. Mais peut-être que ce n'est pas un problème...

Concernant iText, je suis d'accord. J'ai du mal à saisir pourquoi il prend autant de mémoire pour exporter un petit dessin... Peut-être que mon algo n'est pas bon :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
PdfWriter writer = PdfWriter.getInstance(document, new FileOutputStream(this.file));
document.open();
PdfContentByte cb = writer.getDirectContent();
 
// Drawing the page border
Graphics2D g2d = cb.createGraphics(pageHeight, pageWidth);
g2d.drawRoundRect(20, 20, (int)pageHeight-40, (int)pageWidth-40, 20, 20);
g2d.dispose();
 
// Inserting the capturedImage
Image image = Image.getInstance(this.controller.getCapturedImage(), null);
document.add(image);
 
document.close();
writer.close();

[Heimdal]

Ce que tu constates est juste, la JVM ne désalloue jamais de mémoire. Quel intéret aurait-elle à cela d'ailleurs étant donné qu'elle risquerait fort de devoir réallouer cet espace lors d'une prochaine action.?
Si tu ne veux pas allouer beaucoup de mémoire mets un -Xmx faible et laisse le GC bosser davantage.

[DaveRidic]

Je suis d'accord avec toi et je réduirais bien la taille maximale du heap (-Xmx). Cela conviendrait à 95% des cas d'utilisation de mon application.

Seulement, de temps en temps, mon appli a besoin de beaucoup de mémoire. Alors comment faire ? C'est dommage de réserver tout cet espace pour ne l'utiliser que dans 5% des cas !

En fait, j'ai remarqué que ma consommation de mémoire retombe après avoir réduit ma fenêtre principal ; comme s'il fallait réinitialiser l'IHM. J'ai donc trouvé une astuce : après avoir exporté mon PDF, je réduis ma fenêtre et ouvre le PDF fraichement généré... Pendant ce temps, ma JVM se purge !

J'ai participé à une formation Delphi la semaine dernière et j'ai retrouvé avec horreur les "pointeurs". Avec horreur, mais aussi avec plaisir car j'ai appris des tas de trucs sur la gestion de la mémoire.

Le GB de java est génial, mais je trouve qu'il manque de flexibilité, en particulier, dans le cas de grosses opérations, j'aimerais pouvoir allouer et désallouer à la main un certain espace de mon heap.

[thelvin]

Je suis d'accord avec toi et je réduirais bien la taille maximale du heap (-Xmx). Cela conviendrait à 95% des cas d'utilisation de mon application.

Seulement, de temps en temps, mon appli a besoin de beaucoup de mémoire. Alors comment faire ? C'est dommage de réserver tout cet espace pour ne l'utiliser que dans 5% des cas !

En fait, j'ai remarqué que ma consommation de mémoire retombe après avoir réduit ma fenêtre principal ; comme s'il fallait réinitialiser l'IHM. J'ai donc trouvé une astuce : après avoir exporté mon PDF, je réduis ma fenêtre et ouvre le PDF fraichement généré... Pendant ce temps, ma JVM se purge !

Tout cela est inutile. Si la fonction est utilisée une fois, elle sera utilisée deux fois, puis trois, et aussi longtemps que le programme ne sera pas arrêté : le programme a été démarré pour elle, et a donc besoin de cette mémoire.

Si elle n'est pas utilisée, l'espace mémoire n'est pas réservé, et la question ne se pose pas.

Le GB de java est génial, mais je trouve qu'il manque de flexibilité, en particulier, dans le cas de grosses opérations, j'aimerais pouvoir allouer et désallouer à la main un certain espace de mon heap.

C'est souvent à tort. Pas toujours, non, mais souvent. Dans l'exemple donné au-dessus, cela t'aurait permis un chtit mieux. Un petit pas grand-chose, qui aurait fait plaisir aux rares personnes qui surveillent l'utilisation mémoire de leurs programmes sans vraiment comprendre, et qui auraient pu constater que son utilisation diminue quand il n'est pas juste en train de faire quelque chose.
C'est très souvent comme ça.

Une gestion fine de la mémoire, c'est nécessaire dans des cas précis, mais pas courants.

[adiGuba]

Salut,

Ce que tu constates est juste, la JVM ne désalloue jamais de mémoire.

Pas tout à fait ! En fait cela dépend du GC utilisé !

Le problème c'est que par défaut ce dernier peut varier.

• Sur un poste Windows 32bits c'est généralement le GC Serial (-XX:+UseSerialGC).
• Sur un autre OS avec 2 processeur et + de 2Go de mémoire c'est le parallel GC (-XX:+UseParallelGC)
• Sur un OS 64 bits c'est aussi le parallel GC

Le ParallelGC est plus adapté aux applications serveur, et à tendance à libérer la mémoire moins facilement. En fait il considère qu'il y a de forte chance que l'application ait encore besoin de cette mémoire, et qu'il est donc plus intéressant de la conserver plutôt que de la ré-allouer (ce qui est couteux).


Mais en fait le SerialGC est plus adapté aux applications de bureau, ne nécessitant pas trop de mémoire. Donc si tu lances ton application avec -XX:+UseSerialGC tu devrais voir ta mémoire retomber après utilisation...
Tu peux même controller cela avec -XX:MinHeapFreeRatio et -XX:MaxHeapFreeRatio (valeur par défaut : 40 et 70).



A noter également que Java 7 inclut un nouveau GC : G1 (Garbage First), qui libère également la mémoire assez rapidement il me semble...


a++

[tomatoes]

Bonjour,

J'ai exactement le même soucis mon appli client utilise 350 Mo en moyenne sur la journée, et une fois dans la journée autant il y a un pic à 1.2Go et ensuite mon commited memory reste à 1.4Go ce qui laisse beaucoup moins de place aux autres appli du système.
Donc l'option -XX:+UseSerialGC resoudrait le soucis ?

Merci pour votre aide