Discussion :

[biozaxx]

Bonjour à tous,

je fais appel aux specialistes de la gestion de memoire en java !
voici mon probleme : je suis en train de developper une appli qui necessite énormement de memoire (affichage de heatmap)
je suis donc en train de travailler avec un profileur (yourkit) pour detecter les fuites de memoire (et il y en a )

Mon probleme est le suivant : la telemetrie d'utilisation de la memoire du profileur me donne quelque chose de tres different des courbes que l'on peut voir avec le gestionnaire des taches de windows.

En gros d'apres le profileur, la memoire est bien relachée a des phases specifiques de l'appli or dans le gestionnaire des tache cette memoire ne semble pas etre relachée.
Voici les chiffres (Mo) que j'ai relevé pour differentes étapes sur un petit set de données:

profileur: mem utilisée / memoire allouée | gestion. windows: Util. memoire / Taille MV

* 20 / 38 | 71 / 77
* 27 / 39 | 78 / 84
* 40 / 57 | 91 / 106
* 19 / 70 | 109 / 114

avec le profileur on voit bien que lors de la derniere phase la taille de la memoire utilisée diminue or au final dans windows il n'en est rien

merci pour vos eclairsissement eventuels

[woodwai]

A mon avis, ton programme réagit bien (cf les chiffres du profileur) ... mais le profileur lui-même ne libère pas la mémoire!

En effet, un profileur fait tourner le programme en quelque sorte 'dans lui-même ( (dans sa JVM ou dans une thread interne je ne connaît pas les détails) de manière à pouvoir faire le profiling.

Pour moi, ai confiance dans les données de ton profileur (c'est bien pour cela que tu l'utilise) et considère les données de windows comme non pertinance de par l'utilisation du profileur. Pour te prouver la chose, tu peut essayer ton programme sans profileur ...

[biozaxx]

tu as tout a fait raison ... sauf que les données que j'ai enregistré dans le gestionnaire des taches sont celles correspondant a l'appli sans le profileur.
(etant donné que les courbes obtenues sont reproductibles, j'ai fait les test séparement)...


question qui pourait résoudre le probleme : une fois que la memoire a été allouée à la JVM (avec un maximumu defini par -Xmx1024m par exemple) est il possible de forcer la JVM par un moyen quelconque de relacher ce qui n'est plus necessaire ? (car meme avec le profileur on voit bien que la taille allouée ne redescend pas!)

[DevTeam_]

Je n'ai jamais eu l'impression que le gestionnaire de taches intégré à Windows était extrémement fiable quant à la conso mémoire... As-tu essayé avec un autre outil (Process Explorer ou autre) pour t'assurer des chiffres ?

[biozaxx]

non ... je ne connais pas ce soft
je vais essayé de trouver ca et voir ce que ca donne

merci

[elmor]

Je ne sais pas si j'ai bien compris le problème mais ça me semble normal.

Déja au niveau du profiler tu vois uniquement la taille de ta heap et non la taille totale de ta JVM.

Ensuite au niveau système windows tu vois l'utilisation mémoire de tout ton programme donc la "Heap", la "Non Heap" plus de la mémoire supplémentaire utiliséés par les Dll etc...

De plus la mémoire utilisée par un programme java ne peut pas déscendre mais juste monter (du point de vue du système)

Je m'explique. Si je lance mon programe avec un min à 16 MB et un max à 64MB dés le début le programme prendra 16 MB au mini.Mon programme peut utiliser bien moins 16 MB mais java alloue dés la début 16MB pour pouvoir y allouer ses objects dedans. Donc le système voit que ton programme utilise 16MB.
Imaginons que j'alloue pas mal d'objets et j'ai besoin tout d'un coup de plus de mémoire la mémoire de ma jvm passe à 32M. Le système vois cette augmentation de mémoire.
Ensuite un coup de GC et ton programme n'utilise plus de 6MB. Alors oui ton programme n'utilise plus que 6MB mais java ne relache pas la mémoire au niveau système. Java l'a garde au cas où il en aurait besoin plus tard.
Donc le systeme vois que ton programme utilise toujours 32MB de mémoire.

Voilà pourquoi pour un système un programme Java utilises de plus en plus de mémoire. On pourrait croire que le programme utilises moins de mémoire si une partie est "swappée".

En espérant que ça aidera.

[biozaxx]

merci elmor c'est l'explication claire que je cherchais
Concernant la "non heap" je n'avais pas mis les chiffres mais le profileur me donne egalement la taille correspondante, mais comme elle est negligeable par rappart a la heap je l'avais pas mentionnée.

Le truc dont je voulais etre certain, c'est effectivement qu'une fois la memoire allouée a la jvm, java ne relache rien au systeme.

J'ai mon explication, merci a tous pour votre aide

[bassim]

Je comprends pas cette façon de marcher de la JVM, pourquoi ne pas libérer une partie de la mémoire système une fois le garbage Collector passée.

Si par exemple, la quantité libérée par le GC est très grande, la JVM peut de ce fait libérer aussi la mémoire système.

Vos éclaircissements seront les bienvenues ! merci

[Kadir]

Je comprends pas cette façon de marcher de la JVM, pourquoi ne pas libérer une partie de la mémoire système une fois le garbage Collector passée.

Si par exemple, la quantité libérée par le GC est très grande, la JVM peut de ce fait libérer aussi la mémoire système.

Vos éclaircissements seront les bienvenues ! merci

Salut Bassim,

C'est une regle, faut jamais preter à Java de la memoire

Au fait, quand le GC passe, il libére la mémoire dans la heap de la VM Java, qui se trouve dans la heap système du process Java. Par contre, Java ne rend jamais la memoire au Système.

Sans oublier, que ce genre de choses ne sont pas standards, chaque VM a son comportement. Je parle de toute la specifité de la gestion memoire de la VM.

J'ai déjà constaté une différence entre la VM de SUn, et JRockIt