Discussion :

[super_navide]

je pense que les GC est une très bonne inventions.
La libération déterministe de la mémoire peut parfois être nécéssaire pour des raisons de performance, mais dans ce cas on identifie la partie du logiciel qui est critique et on la développe en C++ ou en C.
C'est pour ca qu'a été créer les java native interface.

De plus le gain de productivité gagné avec la gestion automatique de la mémoire est très très important .

la seule chose qui manque à java qui lui permettrait de gagné en puissance serai de pouvoir allouer des objets de taille fixe comme les structures du langage C . sur la pile d'execution .
ce ci serai utile pour faire du calcul vectoriel ou matricielle ...

[zeavan]

voila je vais essayer d'eclaircir ce debat avec ma petite bougie en y repondant de facon chronologique.

1:au commencement le devellopeur pense gc c'est pas bon c'est pour les nuls moi je peux faire aussi bien je suis un grand garcon.

2:ensuite avec le temps , ca devien soulant cette gestion de la memoire , c'est pas mal ce truc ce GC .

3:puis quelque unites de temps passe, le GC c'est une bombe il y a rien a en dire je dort mieux la nuit maintenant.

4:puis queque unites de temps passe , le GC c'est bien mais il manque qq chose et si je revenais au source pour voir maitenant comment je pourrai m'en sortir.

5:puis enfin le gc c'est bien , ils ont fait du bon boulot mais GC ou pas cela depend pas de reponse absolue je sais maitenant faire avec ou sans, tout dependra maitenant des types de projets a executer.

[longbeach]

deneb tu as 20 ans d'experience en programmation, j'en deduis que tu es de la generation gestion de la memoire à l'octet près.
J'ai fais pas mal de C, j'ai perdu des heures avec les pointeurs, les mallocs etc
Quand tu vois toutes les technos qu'il y a aujourd'hui autour de Java tu te dis que tu as autre chose à faire qu'à gérer la memoire à la main.
Merci donc au garbage collector de s'en occuper.

[basnifo]

tu te dis que tu as autre chose à faire qu'à gérer la memoire à la main

Le GC ne résouds pas le pb pour autant ... argument non recevable

Savoir comment fonctionne les allocations / libérations est quand même une des bases de la programmation ...
Tu en aura besoin quel que soit le langage.
La preuve, même en Java ...
Donc c'est important
Donc il faut savoir comment programmer proprement même si c'est compliqué au début à bien tout comprendre ...

[mat.M]

Rapidement, quelques mauvais souvenirs de C++ :
- mauvaise allocation : taille d'un objet dépassant sa taille allouée. Conséquence : l'objet débordait sur un autre pour fonctionner. Du coup l'objet en partie écrasée ne fonctionnait plus bien. On a cherché pendant des heures ce qui n'allait pas dans notre code sur ce sacré objet (une simple boîte aux lettres) avant de comprendre. Erreur que je préfère éviter à l'avenir !
- pile augmentant sans cesse, tuant toute mon appli et pénalisant sacrément mon OS..

Ce ne fut que sur des programmes simples... Je ne parle pas du dépassement de pile, qui certes ne m'est jamais arrivé mais m'a l'air fort fréquent et porte ouverte à bien des attaques...

Pour les fuites de mémoires il y a des outils spécialisés pour ça ( Boundschecker)
Un projet digne de ce nom et pro en C++ devrait avoir recours à ce genre d'outils.
Néanmoins c'est certain qu'ils ne sont pas fiables à 100%.

Pour ce qui est de la pile soit on passe trop d'argument ou des arguments trop gros à une fonction soit ce sont des boucles trop grosses ou qui tournent mal

[kawa]

Je vais essayer d'attaquer la question sous un autre angle (en tentant de ne pas faire dévier le débat).

Un coup d'oeil sur le passé. A mon sens, Java à en partie vue le jour avec l'intention de rationaliser/simplifier des concepts du C++ : la gestion de la mémoire, un modèle objet trop puissant (héritage multiple, généricité, surcharge des opérateurs, notion amitié), et des héritages du C encore une fois trop puissant - les macros. (Cette liste n'étant bien sur pas exhaustive)

Attention, je n'essai pas de dire que ces concepts ne sont pas maîtrisables. Ils le sont par la plupart des développeurs expérimentés. Mais ces points font partie des concepts avancés problématiques et RECURRENTS.

A l'heure actuelle, Java réintègre petit à petit ces concepts avancés. Une impression de tourner en rond ? Possible. Une démarche inutile au final, pas si sur. Qu'avons nous gagner au final ?

- un langage objet propre, mais pas parfait
- une librairie de classe documente et très fournie
- une plus grande accessibilité (on ne la cite que trop rarement)
- une manière simple (mais pas "human error proof") de gérer la mémoire

Sommes nous parvenus à augmenter la productivité de nos développeurs ?
Difficile à mesurer, mais j'aime à croire que oui.

Sommes nous parvenus à la solution magique qui fiabilise complément le code ?
Non.

Ces concepts avancés sont-ils à proscrire et à oublier ?
Non, ces concepts adressaient des problématiques réelles pas des réflexions philosophiques. Et, il nous faut traiter ces problématiques qui ressurgissent.

Comme la généricité, la gestion fine de la mémoire est un sujet qu'il faudra adresser. La question est de savoir comment le faire sans remettre en cause la fiabilité de la plateforme Java. Il faut se rappeler que ce besoin de gérer finement la mémoire constitue une minorité de cas de figure, une programmation propre suffit pour la grande majorité des cas.

[christopheJ]

Attention, il faut aussi voir le contexte de l'application

Les pauses induites par le garbage collector dans le cadre d'une application web ne me semble pas des plus critiques. Le client peut tres bien attendre sa réponse quelques dixiemes de seconde de plus.... Il y a tellement de facteurs pouvant ralentir une connexion web.

Dans le cas du temps réel, ces pauses sont effectivement génantes. C'est d'ailleur pour cela qu'il existe une spécification de Java pour le temps réel Java RTS : http://java.sun.com/javase/technologies/realtime.jsp avec une gestion du GC différente. On ne va pas courir un footing en soulier vernis, on ne fait pas du temps réel avec un systeme qui n'est pas pensé pour.

Si on se place dans les contextes web et desktop, le GC n'est pour moi pas génant et, au contraire, permet de se concentrer sur le code métier plutot que sur des problemes de "machinerie"
Dans le contexte de l'embarqué (Java ME), le garbage collector reste problematique, même si son implémentation est différente, c'est encore en cours d'amélioration.

[Franckintosh]

J'ai deux remarques à faire :
- L'expression française "fuite de mémoire" existe et est significative.
- Oublier qu'on a rangé le vélo cassé de papy et la casserole rouillée de mamy dans le placard du fond ce n'est pas une fuite de mémoire, c'est du stockage d'antiquités obselètes. Une fuite de mémoire c'est quand on a perdu la clé de la porte du placard.

[FremyCompany]

Je tiens à faire remarquer que sous les langages .Net, le garbage collector (outre le fait qu'il me semble plus efficace que celui de Java, bien que je ne tienne pas à entrer dans le débat .Net vs Java) permet de détruire soi-même et à tout momment l'instance d'un objet, si le besoin s'en fait sentir !

En effet si vous déclarer une variable en début de fonction et qu'elle ne sert que peu de temps et que votre fonction est longe ensuite, vous pouvez décider que l'objet peu être relaché...

Alors si vous tenez à discuter des avantages inconvénient du GC sous Java, aller dans le forum Java Sinon, il vous faut prendre en compte les évolutions que celui-ci a adopté dans les autres langages et que Java, qui sait, adoptera peut-être un jour lui aussi !

Pour moi GC, y pas mieux pour gagner du temps, autant pour celui qui sait bien programmer que pour celui qui programme déjà depuis longtemps.

Et la methode manuelle, pas mieux quand on ne sait pas programmer ! La vous aller m'arrêter, c'est le contraire ! Ben non... Reprenons mon exemple de variable déclarée au début d'une fonction très longue et inutilisé très vite après : qu'est-ce qui vous a empeché de faire une fonction ? (Sub, function, void, ou tout ce que vous voulez, selon votre language) Ben oui, la sous-fonction, même utilisée une fois, permet de relacher l'instance de votre variable une fois la sous-fonction terminée et donc au final d'augmenter la puissance de votre application !

Deplus ici, l'utilisation est recommendable, vu que votre fonction de départ était longue... alors pourquoi ne pas la diviser en plusieurs petites sous fonction, ayant chacune une fonction déterminée, et surtout, un nom permettant d'y voir clair en lisant le code de la nouvelle "grande" fonction épurée !

Le problème de la variable inutilisée est donc un vis de programmation...

Une autre méthode, pour le parresseux cette fois : vous assignez null (ou Nothing, selon le language) à votre variable, et voila le travail terminé ! Sinon, pour ce qui est des références dans les autres objets, faut savoir les gerer dans les fonctions de destruction de l'objet...

Je dis peut-être n'importe quoi, je suis encore assez jeune mais il me semblait que mon avis ne reflète pas trop cette jeunesse

Sinon, je suis ouvert à toute remarque, critique ou chose auquel je n'aurais pas pensé

[kawa]

Je tiens à faire remarquer que sous les langages .Net, le garbage collector (outre le fait qu'il me semble plus efficace que celui de Java, bien que je ne tienne pas à entrer dans le débat .Net vs Java) permet de détruire soi-même et à tout momment l'instance d'un objet, si le besoin s'en fait sentir !

Autant que je sache la gestion "manuelle" de la mémoire n'est accessible qu'en C++/CLI, et que tu choisis ta méthode de libération au moment de l'instanciation par un appel à gcnew ou new. Tu n'as pas de possibilité de décider de libérer un objet "managed" sans demande une collecte au GC.

A moins que tu ne fasses référence à l'emploi de Dispose(), mais il y a méprise de ta part sur l'utilisation de ce pattern.

Le pattern Dispose sert à libérer les ressources sous-jacentes "unmanaged" liées à une classe "managed". Pour la partie "managed" de l'instance, la collecte s'effectue comme d'ordinaire.

Un excellent article sur le sujet
http://www.bluebytesoftware.com/blog...3-20c06ae539ae


Bon week

[Killing Joke]

Il y a un point qui m'a toujours chagriné avec les garbages collectors, c'est la perte des Destructeurs.
Alors oui bien sûr on peut très bien vivre sans, on peut faire une méthode finalize() et l'appeler lorsque, au niveau programmation, on sait qu'on a fini de travailler avec cet objet, çà revient presque au même qu'un destructeur.
Mais n'empêche, avoir une méthode dont on est sûr qu'elle s'exécutera à la fin de l'objet, à quelque moment que cette fin arrive (lorsque l'objet est désalloué manuellement dans le code, ou au pire à la fin de l'exécution de l'appli), c'est une bonne chose (et c'est justement très "objet" comme philosophie), pour être sûr de fermer ses ressources (quelles qu'elles soient), dumper dans une log la survenue de l'événement "destruction de l'objet", etc.
Franchement, çà me manque.

Sinon deux remarques en passant : je vois souvent l'exemple "le GC marche mieux qu'une allocation manuelle par ex. dans le cas d'une boucle qui crée un objet temporaire à chaque itération". Je trouve l'exemple un peu biaisé : il est quand même rare de faire ainsi, souvent on crée l'objet une seule fois avant la boucle et il est seulement réinitialisé à chaque tour de boucle, il n'y a donc qu'une seule allocation / désallocation (et x réinitialisations, ou simplement réassignations des propriétés), donc en pratique le GC n'a pas plus d'avantage qu'une désallocation manuelle.

Ensuite pour le "désallouer au plus tôt", j'ai déjà eu des cas de figures où çà m'a manqué, parce que les structures sont complexes et qu'on ne se rend pas toujours compte de ce que représente la création d'un nouvel objet ou le clonage d'un objet (merci JProbe pour débugger). Et heureusement qu'on peut "aider" le GC en passant à null les références sur les objets dont on n'a plus besoin..

[deneb]

Sinon deux remarques en passant : je vois souvent l'exemple "le GC marche mieux qu'une allocation manuelle par ex. dans le cas d'une boucle qui crée un objet temporaire à chaque itération". Je trouve l'exemple un peu biaisé : il est quand même rare de faire ainsi, souvent on crée l'objet une seule fois avant la boucle et il est seulement réinitialisé à chaque tour de boucle, il n'y a donc qu'une seule allocation / désallocation (et x réinitialisations, ou simplement réassignations des propriétés), donc en pratique le GC n'a pas plus d'avantage qu'une désallocation manuelle.

C'est un truc maintes fois vu ici : le GC permet de mieux sans sortir quand on programme comme un cochon.
C'est comme ça que je retrouve le code suivant dans notre appli :

Code :

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

1
2
3
4
5
6
public void mouseMove(MouseEvent mouseEvent) 
{
	Point mousePosition = new Point(mouseEvent.x , mouseEvent.y);

   	//calculs utilisant mousePosition.
}

Alors oui dans ce cas, le GC s'en sortira mieux qu'une désallocation manuelle.
Mais on est là dans un cas type de mauvais usage de la mémoire.

[davcha]

Il y a un point qui m'a toujours chagriné avec les garbages collectors, c'est la perte des Destructeurs.

http://www.c-sharpcorner.com/Code/20...estructors.asp

[deneb]

[...]existe une spécification de Java pour le temps réel Java RTS : http://java.sun.com/javase/technologies/realtime.jsp avec une gestion du GC différente. On ne va pas courir un footing en soulier vernis, on ne fait pas du temps réel avec un systeme qui n'est pas pensé pour.

Merci beaucoup. Je ne connaissais pas...
C'est hyper intéressant.

[FremyCompany]

Autant que je sache la gestion "manuelle" de la mémoire n'est accessible qu'en C++/CLI, et que tu choisis ta méthode de libération au moment de l'instanciation par un appel à gcnew ou new. Tu n'as pas de possibilité de décider de libérer un objet "managed" sans demande une collecte au GC.

A moins que tu ne fasses référence à l'emploi de Dispose(), mais il y a méprise de ta part sur l'utilisation de ce pattern.

Le pattern Dispose sert à libérer les ressources sous-jacentes "unmanaged" liées à une classe "managed". Pour la partie "managed" de l'instance, la collecte s'effectue comme d'ordinaire.

Un excellent article sur le sujet
http://www.bluebytesoftware.com/blog...3-20c06ae539ae


Bon week

Je ne parlais pas de la méthode Dispose qui, en effet, ne fait pas partie du GC...

Je parlais plutot de la méthode Finalize (VB .Net) ou du destructeur (equivalent de Finalize (VB) dans les autres languages) d'instance (C#, ...) (et oui ca existe, et c'est pas moi qui l'ai inventé, cette méthode est exécutée POUR désallour ton objet (Object.Finalize()) et peut être surchargée à chaque nouvelle classe) que tu peux (en VB du moins) appeler à n'importe quel momment pour liberer ton objet.

Bien que je ne connaisses pas les effets exacte de cette fonction, je pense qu'elle permet déjà d'obtenir simplement une destruction (partielle au moins) de l'objet.

Ensuite, après exécution de la méthode Finalize, tu dois effectuer une opération "manuelle" pour conserver la stabilité du GC..

Voici donc, en VB .Net, la méthode à utiliser pour force la libération de la mémoire d'un objet :

Code :

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

1
2
Obj.Finalize()
System.GC.SupressFinalize(Obj)

Sinon en effet, la class GC possède les fonctions suivantes (plus d'autres qui me semblait moins intéressante) :

Code :

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

1
2
3
GC.KeepAlive(Object) 'L'objet passé en argument n'est plus concerné par les collectes du GC
GC.Collect() 'Force le GC à vider la mémoire
GC.WaitForPendingFinalizers() 'Demande au thread actuel d'attendre la fin de des collectes en cours avant de reprendre son exécution

[zais_ethael]

Salut à tous.
Boin, je débarque un peu dans la discussion et je n'ai pas trop envie de relire tous les précédents posts. Je vais donc me concentrer principalement sur le sujet initial alors excusez moi si je cite des choses déja citées.
A pour ou contre le garbage collector je dirais qu'il n'y a pas à avoir de pour ou de contre puisque ce n'est pas une fin en soit. Le garbage collector est une obligation technique lorsqu'on veut adopter un style de programmation comme celui du java. J'entends par la le comptage de réfèrence pour les objets.
L'avantage que procure cette façon de programmer n'est pas des plus petits: ca permet de stocker de façon transparente nos objets sur le tas, donc de pouvoir les utiliser sans connaitre leur taille à la compilation ce qui est en quelque sorte le must de la programmation objet (un objet d'une classe dérivée pouvant être plus grand qu'un objet de sa classe mère).
On pourrait considérer qu'un système à base de smart pointer à comptage de réfèrence peut suffire, mais c'est sans compter le problème des réfèrences cycliques qu'on ne peut ignorer. Sans compter que, contrairement à ce que j'ai déja entendu, les smart pointers n'appelent pas du tout les destructeurs de facon déterministe. Certes ils le font lorsque le nombre de réfèrence tombe à zero, mais la vraie question est "Peut on seulement savoir quand le nombre de réfèrence tombe à zero?". La réponse: non, à moins d'avoir en permanence une vue d'ensemble de tout son code, ce qu'il est vain d'essayer de faire puisqu'un projet ne fait en général que grandir tandis que la capacité de mémorisation de l'être humain est limitée.
J'en conclus donc que la seule alternative au garbage collector est de programmer dans un style C++, qui j'en conviens est fonctionnel mais qu'on ne peut pas qualifier de 100% objet (pour ce qui est de savoir si on a vraiment la nécessité d'un langage 100% objet c'est un autre débat).

Aute chose: le garbage collector n'est pas forcément ce qui rend le java lent, il y a d'autres facteurs. Nottament le fait que ce ne soit pas un langage compilé. La seule façon de vérifier serait de faire des tests comparatifs sur des langages complilés implémentant aussi un garbage collector. Je n'en connais que deux: les java compilé avec GCJ et le D. Mais l'un et l'autre sont assez peu utilisés, donc moins soutenus et donc peut être moins au point et moins rapides.

[adiGuba]

Il y a un point qui m'a toujours chagriné avec les garbages collectors, c'est la perte des Destructeurs.

Le GC ne signifie pas forcément abscence de destructeur.
Ils sont présent en Java avec la méthode finalize(), et il semble que ce soit également le cas dans les langages de .NET...

La seule différence c'est que tu ne peux pas prédir le moment exact où cette méthode s'exécutera...

a++

[deneb]

Salut à tous.
A pour ou contre le garbage collector je dirais qu'il n'y a pas à avoir de pour ou de contre puisque ce n'est pas une fin en soit. Le garbage collector est une obligation technique lorsqu'on veut adopter un style de programmation comme celui du java. J'entends par la le comptage de réfèrence pour les objets.
L'avantage que procure cette façon de programmer n'est pas des plus petits: ca permet de stocker de façon transparente nos objets sur le tas, donc de pouvoir les utiliser sans connaitre leur taille à la compilation ce qui est en quelque sorte le must de la programmation objet (un objet d'une classe dérivée pouvant être plus grand qu'un objet de sa classe mère).

Est-ce réellement un avantage ? En quoi ?

• Temps d'exécution ? Sûrement pas !
• Temps de dev ? j'en doute.
• Fiabilité ? D'expérience non...pas mieux qu'en C++.

[...]J'en conclus donc que la seule alternative au garbage collector est de programmer dans un style C++, qui j'en conviens est fonctionnel mais qu'on ne peut pas qualifier de 100% objet (pour ce qui est de savoir si on a vraiment la nécessité d'un langage 100% objet c'est un autre débat).

That's the point !!
Une VM, les API Java et une syntaxe C++, voila ce qui serait un vrai bonheur.

Aute chose: le garbage collector n'est pas forcément ce qui rend le java lent, il y a d'autres facteurs. Nottament le fait que ce ne soit pas un langage compilé.

Java EST un language compilé !
Ce qui le rend plus lent que le C++ (dans certains cas) c'est surtout la gestion de la mémoire...Et oui encore
Et c'est essentiellement dû à l'impossibilité d'accèder directement à la mémoire pour faire des lectures/copies de zones, à l'absence de tableaux de structures....et autres choses sympa qui permettent d'aller vite en C/C++.
Sinon pour le reste, il n'y a pas plus de 10-15% d'écart de vitesse entre Java et C++, ce n'est pas ce que j'appelle "lent".

[Aldebaranl2]

Bonjour à tous.

Pour ma part, je pense que le GC facillite beaucoup la gestion de la mémoire. Bien sûr, le programmeur doit faire en sorte de ne pas se reposer dessus à 100%, et vérifier qu'il n'abuse pas de la création et la destruction d'objets. L'utilisation des differentes références (soft, weak et phantom) aident le gc à la libération de la mémoire.

Néanmoins, il serait bien de pouvoir le controler un peu plus, et cela sur 2 points :
- Possibilité de l'activer/désactiver. Pourquoi? Je me base sur du J2ME par exemple. Le J2ME est très differet du J2SE car il faut gerer les ressources quasiment à l'octet près. Imaginez que vous devez charger 3 images (decors, sprits, etc...) et que ces 3 images arrivent juste à la limite de la place disponible. Le passage du GC fait augmenter de manière discrete la quantité de mémoire utilisée. Discrète, mais assez pour tout faire planter. Résultat --> Une jolie OutOfMemeryException. Si on pouvais désactiver le GC, cela ne se produirai pas, et on pourrai à la limite gerer nous même la mémoire comme en C.
- possibilité de controler son passage : Encore un exemple J2ME (meuh nan j'abuses pas ^^). Chargement des ces 3 images, puis désinstanciation. Appel de system.gc(), puis attente de 5sec, puis appel de system.gc(), puis attente de 5sec, puis...etc... puis chargement d'une 4ème image --> OutOfMemoryException ! Pourquoi ? Tout simplement car l'appel de la méthode System.gc() ne force pas le gc à passer, mais lui dit qu'il PEUT passer. Dans notre cas, il n'est pas passé.


Moralité (pour ma part bien sûr) GC oui, mais avec modération et contrôle

[christopheJ]

Java EST un language compilé !
Ce qui le rend plus lent que le C++ (dans certains cas) c'est surtout la gestion de la mémoire...Et oui encore
Et c'est essentiellement dû à l'impossibilité d'accèder directement à la mémoire pour faire des lectures/copies de zones, à l'absence de tableaux de structures....et autres choses sympa qui permettent d'aller vite en C/C++.
Sinon pour le reste, il n'y a pas plus de 10-15% d'écart de vitesse entre Java et C++, ce n'est pas ce que j'appelle "lent".

La compilation genère un bytecode qui est ensuite recompilé à la volée lors de l'exécution. C'est le compilateur JIT (Just In Time) qui s'en charge et permet donc des optimisations propres à la machine sur laquelle tourne le programme (mono ou biproc, coprocesseur mathématique, ...). Cela permet d'être parfois plus performant que du code compilé de façon "générique" (les binaires des programmes qu'on vend dans le commerce...)