[JVM]Gestion de la mémoire

**Crypt** · 28/12/2005, 22h53

Je m'interroge sur des questions de performances de mon projet actuel.

C'est sans doute une question de base mais je la pose quand même =

par exemple

String st=new String("ttt");

utilise t'il plus de mémoire que

new String("ttt");

?

**HNT** · 28/12/2005, 23h41

Ben c'est simple le premier cas utilise plus de mémoire mais est le seul correct ! il utilise plus de mémoire parce-qu'il crée une reférence (ou pointeur) nommé st. Ce n'est en fait qu'une variable qui contient une adresse, celle de début (en mémoire) de l'objet que tu référence. Les références sont indispensable car ce sont elles qui te permettent d'accéder à tes objets par conséquent si tu te contente d'écrire

new String ("ttt");

il est vrai que tu économisera l'espace mémoire d'une référence mais ou est l'intéret vus que tu ne saura jamais accéder à cet objet ? Je n'ai jamais essayé mais logiquement ca ne devrait pas passé la compilation (tel quel en tout cas, si tu écrit System.out.print(new String("ttt")) c'est bon mais ca implique que tu ne puisse utilisé nul part ailleurs la chaine ttt)

**Pill_S** · 29/12/2005, 01h10

Hello,

sur le principe ce n'est pas faux, mais je complèterai en disant ceci:

il n'y a pas de problème à instancier des objets sans garder leurs références à portée de main... c'est très fréquent et lorsqu'il ne s'agit que d'objets intermédiaires utilisés à 1 seul endroit cela permet de simplifier le code.

Cependant, la classe String, dans la plupart des JVM, gère un pool de chaînes en interne: quand on écrit "toto", il n'y a pas forcément de nouvelle chaîne créée en mémoire, si une chaîne "toto" existe déjà dans la mémoire cela renvoie sa référence... en instanciant explicitement les chaînes, on court-circuite cette optimisation en forçant la création d'une nouvelle chaîne...

Code :

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

1
2
3
4
5
6
7
8
 
// sur des JVM récentes 
String s1 = "toto";
String s2 = "toto";
System.out.println(s1 == s2); // true
 
s2 = new String("toto");
System.out.println(s1 == s2); // false !

**sinok** · 29/12/2005, 01h54

Sauf qu'en général il vaut mieux éviter d'utiliser le == sur des chaines

sauf pour du null

**Gfx** · 29/12/2005, 02h43

L'utilisation de == est parfaite ici pour demontrer ce que disait Pill_S. La methode equals() ne prouverait rien.

**sinok** · 29/12/2005, 04h35

je ne remettais pas en cause l'utilisation dans le cas présent, mais apportait juste une précision, quend on voit le nombre d'erreurs qui résultent de la confusion .......

**Crypt** · 29/12/2005, 12h03

Envoyé par HNT

Ben c'est simple le premier cas utilise plus de mémoire mais est le seul correct ! il utilise plus de mémoire parce-qu'il crée une reférence (ou pointeur) nommé st. Ce n'est en fait qu'une variable qui contient une adresse, celle de début (en mémoire) de l'objet que tu référence. Les références sont indispensable car ce sont elles qui te permettent d'accéder à tes objets par conséquent si tu te contente d'écrire

new String ("ttt");

il est vrai que tu économisera l'espace mémoire d'une référence mais ou est l'intéret vus que tu ne saura jamais accéder à cet objet ? Je n'ai jamais essayé mais logiquement ca ne devrait pas passé la compilation (tel quel en tout cas, si tu écrit System.out.print(new String("ttt")) c'est bon mais ca implique que tu ne puisse utilisé nul part ailleurs la chaine ttt)

ça ne se voit pas dans les exemples que je donnais mais en fait ça a un intéret : au moment de la génération d'un terrain pour un jeu je crée des objets de divers type que je stocke ensuite dans une grille.
Les objets sont ensuite accessibles dans la grille.

donc au lieu de faire =

Code :

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

1
2
3
4
5
6
Door truc=new Door("Une porte",false,150,false,false,
	"standarddoor","Gate",true,"./images/doors/door0.gif",
	"./images/doors/openDoor0.gif","./images/walls/roomWall33.gif",
	"./sons/door_open.wav","./sons/door_close.wav");
 
grille[17][26].add(truc);

je peux faire =

Code :

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

1
2
3
4
grille[17][26].add(new Door("Une porte",false,150,false,false,
	"standarddoor","Gate",true,"./images/doors/door0.gif",
	"./images/doors/openDoor0.gif","./images/walls/roomWall33.gif",
	"./sons/door_open.wav","./sons/door_close.wav"));

et économiser de la mémoire.

Merci à tous pour vos réponses.

**adiGuba** · 29/12/2005, 13h16

Salut,

Envoyé par Crypt

et économiser de la mémoire.

Tu n'économises pas de la mémoire puisque la référence de l'objet est stocké dans grille[17][26].

Et de toute manière il s'agit d'une simple référence ce qui ne représente quasiment rien... Si tu as des problème de mémoire il y a peu de chances de cela vienne de là...

a++

PS : j'ai édité ton message pour ajouter les balises [code] et mettre des saut de ligne dans le code afin de rendre le tout plus lisible

**Floréal** · 29/12/2005, 15h46

Je profite de ce post pour demander si en java il est possible d'écrire des destructeurs. J'ai éssayé d'en écrire un comme en C++, mais ca n'a pas plus au compilateur. J'ai rien trouvé concernant les destructeurs dans les FAQs alors je pose la question ici (peut être pas regardé suffisemment attentivement).

**Buch'** · 29/12/2005, 15h48

normal le garbage collector est là pour çà

**Beurkh** · 29/12/2005, 16h14

Envoyé par Buch'

normal le garbage collector est là pour çà

il me semble que le garbage collector ne fait pas tout (fermeture des connexions réseaux, de fichier,ect...), la methode finalize() peut etre utilisée.
Quand a sa reel utilité .... euuuh

**Gfx** · 29/12/2005, 17h10

En regle generale il ne faut pas utiliser finalize() car on ne peut pas prevoir quand elle sera invoquee. Bref, le garbage collector fait tout mais cela n'empeche pas les fuites memoires dans des cas bien particuliers (mais tres rares).

**Mister Nono** · 29/12/2005, 23h54

Pour que gc() fasse sont travail, il est bien de mettre son objet à null quand il n'est pas utilisé.

Quand aux références des objets, il n'est pas toujours utiles de les écrire en dur : il suffit de les placer dans un conteneur comme un tableau.
Cela permet de coder sans mentions explicites et d'écrire des programmes bien plus dynamiques (ou plus adaptatifs face aux différentes situations).

Enfin, le méthode finalize() est au moins appelée lors de la fermeture de l'application : cela permet par exemple de fermer les ports encore ouverts en y plaçant dedans le code approprié.

A+.

**Gfx** · 30/12/2005, 00h05

Pour que gc() fasse sont travail, il est bien de mettre son objet à null quand il n'est pas utilisé.

Non.

Enfin, le méthode finalize() est au moins appelée lors de la fermeture de l'application : cela permet par exemple de fermer les ports encore ouverts en y plaçant dedans le code approprié.

Non plus.

Cf ici : http://www-128.ibm.com/developerworks/java/library/j-jtp01274.html

**lunatix** · 30/12/2005, 00h06

Envoyé par Mister Nono

Pour que gc() fasse sont travail, il est bien de mettre son objet à null quand il n'est pas utilisé.

non, c'est une legende urbaine. ca n'aide en rien (y'a un article d'ibm la dessus, mais je sais plus ou)

**Pill_S** · 30/12/2005, 11h27

Envoyé par lunatix

non, c'est une legende urbaine. ca n'aide en rien (y'a un article d'ibm la dessus, mais je sais plus ou)

le fait de placer des références à null ne va pas libérer l'objet directement...

seulement, si l'on garde des références obsolètes dans tous les coins, cela va empêcher le gc de faire son travail... en les mettant à null, on favorise la libération de mémoire au plus vite... dans certains cas cela peut être utile

Code :

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

1
2
3
4
5
6
7
8
 
Object o = new VeryBigObject(); // big o
...
 
for(int i=0; i<Integer.MAX_VALUE; i++)
  process(i);
 
o = null; // o est libéré mnt, on aurait pu le faire avant...

**Crypt** · 31/12/2005, 13h16

Pour mes soucis de mémoire j'ai localisé une brouette entière d'instances inutiles. (pour un jeu, dans un tableau à deux dimensions d'ArrayLists, je remplissais le terrain avec des objets Sol et Herbe en créant à chaque fois une instance de ces objets pour chaque case alors que je n'avais besoin que d'en créer un seul)
(c'est un rogue like =)
http://cryptmaster.free.fr/cryptrl/crl116.jpg

Toutefois il y a un truc que j'aimerais bien savoir = le developpeur de son côté peut augmenter la mémoire de sa JVM * , soit, mais qu'en est-il de l'utilisateur standard qui n'a installé que le minimum indispensable pour faire tourner des appli java et qui n'a probablement pas envie de se taper de la config en plus ?
J'ai cru comprendre qu'il n'existait pas de moyen d'augmenter cette mémoire attribuée à la JVM en passant directement par le code, ce que je trouve assez curieux. Me trompe-je ?

* ce que je n'arrive d'ailleurs pas à faire. J'ai bien essayé dans l'invite de commandes de manipuler des -Xms et autres -Xmx mais sans succés.
Actuellement ma JVM est limitée à 64mo. Pour l'instant ça n'est pas génant mais on ne sait jamais ça pourrait le devenir par la suite.

**Gfx** · 31/12/2005, 13h28

Je parle des flags -Xmx etc. ici : http://www.progx.org/index.php?section=replies&newsid=314

Ne confonds pas la memoire utilisee, la memoire virtuelle, la memoire allouee au heap, etc. Une application Java augmentera la memoire utilisee tant que cela restera entre les valeurs limites du heap. C'est tres rare de devoir modifier ses valeurs et c'est souvent signe d'un gros probleme dans le code.

**Crypt** · 31/12/2005, 14h12

Une application Java augmentera la memoire utilisee tant que cela restera entre les valeurs limites du heap.

a priori, si j'ai bien compris,c'est le heap de ma JVM qui est actuellement limité à 64Mo.

**Gfx** · 31/12/2005, 14h20

Modifie simplement le fichier de lancement de ton application (.sh, .bat, .exe ou que sais-je) pour augmenter la limite superieure du heap.

Je te conseille de lire egalement ceci :
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html
http://java.sun.com/docs/hotspot/VMOptions.html

Tout depend en fait de ta JVM. Avec une JVM 1.4 la valeur par defaut est de 64 Mo si je me souviens bien, mais la JVM 1.5 utilise 1/64 de la memoire totale disponible pour Xms et 1/4 pour Xmx (cf ici http://java.sun.com/docs/hotspot/gc5.0/ergo5.html)

[JVM]Gestion de la mémoire

Java

Vue hybride

Discussions similaires

Partager

Partager