Discussion :

[deneb]

Note : ce débat a commencé sur le débat C# Versus Java


J'ai vu pas mal de monde dans ce thread citer le garbage collector de Java comme un avantage...
N'y a t-il personne d'autre que moi pour penser que cette gestion auto est la pire connerie que Sun ait commise sur ce language (qui par ailleurs est plutôt réussi) ?
Le concept même de GC est pour moi un non sens... Quel que soit le language.

J'ai aussi utilisé un GC en C++ dans mon jeune temps et la conclusion fut la même : merdique, inutile, gaspillage de ressources et pire que tout : source de memory leak !!!

[adiGuba]

Le concept même de GC est pour moi un non sens...quelque soit le language.

Je ne suis pas d'accord, le GC est un gros avantage. D'ailleurs, si je ne me trompe pas, .NET utilise également un GC...

merdique, inutile, gaspillage de ressources et pire que tout : source de memory leak !!!

Le GC de Java ne m'a jamais posé de tel problème...
Maintenant il est facile de faire exploser le GC en lui faisant créer un grand nombre d'objet temporaire... mais c'est plus une faute de programmation qu'un problème de GC à mon avis...

Maintenant, c'est sûr que selon la cible de l'application, ce n'est pas forcément la meilleure solution et que la gestion manuelle de la mémoire peut être plus performante...

a++

[deneb]

En fait je ne vois pas en quoi le GC apporte un plus...
Dans le pire des cas, sachant que le GC est là, le développeur ne se soucie pas le moins du monde de sa mémoire...et ça monte, ça monte.

Donc vous me direz que la présence d'un GC ne dispense pas d'une gestion stricte de sa mémoire...(j'en sais qq chose).
Mais dans ce cas si je dois continuer à gérer ça moi même, autant le faire jusqu'au bout car je sais le faire bien mieux que le GC...et surtout au bon moment !

Je n'ai jamais eu de pb de fuite de mémoire en C++ alors qu'en Java c'est assez fréquent et en plus elles sont beaucoup plus difficiles à repérer.

Bref, le GC c'est sympa pour les débutants on pour faire des petits progs, mais pour écrire un serveur d'appli ...

[adiGuba]

En fait je ne vois pas en quoi le GC apporte un plus...
Dans le pire des cas, sachant que le GC est là, le développeur ne se soucie pas le moins du monde de sa mémoire...et ça monte, ça monte.

Non cela ne monte pas puisque le GC libèrera la mémoire inutilisé !!!

Le GC apporte plusieurs avantages :

• On n'a pas à se soucier de la durée de vie d'un objet. Il sera quand même désalloué proprement lorsqu'il ne sera plus utilisé.
• On peut facilement partager un objet entre plusieurs autres objets, sans se soucier de devoir le désallouer (le GC s'en chargera lorsque l'objet n'est plus référencé). Cela permet d'utiliser le pattern des classes immuables et ainsi d'économiser de nombreuses créations d'objet (pas de copie d'objet à tout bout de champs !).
• Le GC optimise les allocations/désallocations, en effectuant des traitements par bloc. Si tu crées/détruits 1000 objets, le GC ne fera que quelques allocations/désallocations de mémoire (voir aucune). Dans bien des cas cela peut être plus performant qu'une gestion manuelle...
• La gestion des objets alloué par le GC est très rapide, car il alloue des blocs de mémoire entiers.

Bien sûr cela a des désavantages :

• A un instant précis, il consomme plus de mémoire qu'il n'en a besoin, afin de prévenir les futures allocations. Par exemple au démarrage de l'application il alloue par défaut 2 Mo de mémoire (si je ne me trompe pas).
• Il peut être nécessaire de le configurer selon les besoins de l'application (Pour plus de détail, lire : La gestion de la mémoire par le Garbage Collector par Romain Guy)
• On ne connait pas le moment exact de la libération des objets (même si on peut le savoir en utilisant les PhantomReference : Comprendre les Références en Java)

Donc vous me direz que la présence d'un GC ne dispense pas d'une gestion stricte de sa mémoire...(j'en sais quelque chose).

Disons que la gestion de la mémoire est différente. En Java il est nécessaire de "perdre" les référence des objets inutilisés afin d'autoriser le GC à les libérer. La plupart des "memory leak" en Java viennent du fait que l'on conserve des références inutilement...

Mais dans ce cas si je dois continuer à gérer ça moi même, autant le faire jusqu'au bout car je sais le faire bien mieux que le GC...et surtout au bon moment !

Si tu le dis...
Personnellement je préfère me concentrer sur le code métier de mon application...

Je n'ai jamais eu de pb de fuite de mémoire en C++ alors qu'en Java c'est assez fréquent et en plus elles sont beaucoup plus difficiles à repérer.

J'ai eu des problèmes de mémoire avec pas mal de langage, mais je ne vois pas en quoi elles sont plus fréquentes et plus difficile à repérer avec Java ???

Bref, le GC c'est sympa pour les débutants on pour faire des petits progs, mais pour écrire un serveur d'appli ...

Au contraire, le GC n'est pas très utile aux débutants ! D'ailleurs dans des langages comme le C/C++, ils utilisent généralement pas l'allocation dynamique...

C'est dans le cadre de grosses applications que le GC devient très utile, puisqu'on a généralement de gros besoins d'allocation dynamique...


a++

[deneb]

Débat intéressant isn't it ?
En fait on fait plus de leak avec Java qu'en C++ car justement Java facilite (encourage ?) la gestion à la méthode porcus.
Alors qu'en C++ j'utilisais une stragégie d'allocation désallocation très stricte...j'ai perdu cette bonne habitude du fait du GC. (ainsi que la quasi totalité de développeurs java avec qui j'ai pu bosser, et il y en a un paquet).
Le partage d'objets n'est pas du tout un pb sans GC...ou ça met en évidence un mauvais design.

D'une manière générale, je trouve que le fait de déresponsabiliser le developpeur sur la gestion de la mémoire tend à faire des programmes qui consomment le triple de mémoire que nécessaire.

[adiGuba]

En fait on fait plus de leak avec Java qu'en C++ car justement Java facilite (encourage ?) la gestion à la méthode porcus.

Non. Je pense juste que la "méthode porcus" est juste plus vite sanctionné pour une application C++ que Java à cause (ou grâce) au GC qui "corrigera" un certain nombre de ces problèmes...

Mais quel que soit le langage la "méthode porcus" entrainera des problèmes

Le partage d'objets n'est pas du tout un pb sans GC...ou ça met en évidence un mauvais design.

Mais il faut avouer que c'est bien plus complexe à mettre en oeuvre sans GC...

D'une manière générale, je trouve que le fait de déresponsabiliser le developpeur sur la gestion de la mémoire tend à faire des programmes qui consomment le triple de mémoire que nécessaire.

Il faut surtout savoir travailler avec les outils qu'on a : si on utilise un GC cela ne vaut pas dire que l'on doit complètement ignoré la gestion de la mémoire.

Au contraire il faut prendre en compte le GC, et limiter au minimum le scope des différents objets temporaires...

Pour moi il s'agit plus d'erreur de programmation (ou de fainéantise)...



Enfin concernant les "memory leak" : avec un GC on ne peut pas vraiment parler de "memory leak" puisque cela signifie que l'on conserve toujours une référence vers l'objet...

a++

[robert_trudel]

Je n'ai jamais eu de pb de fuite de mémoire en C++ alors qu'en Java c'est assez fréquent et en plus elles sont beaucoup plus difficiles à repérer.

tu dois être meilleur que l'élite... car c'est une des erreurs les plus fréquentes... même chez les pro

[Luc Hermitte]

Non cela ne monte pas puisque le GC libèrera la mémoire inutilisé !!!

Le GC apporte plusieurs avantages :

a- On n'a pas a se soucier de la durée de vie d'un objet. Il sera quand même désallouer proprement lorsqu'il ne sera plus utilisé.

b- On peut facilement partager un objet entre plusieurs autres objets, sans se soucier de devoir le désallouer (le GC s'en chargera lorsque l'objet n'est plus référencé). Cela permet d'utiliser le pattern des classes immuables et ainsi d'économiser de nombreuse création d'objet (pas de copie d'objet à tout bout de champs !).

c- Le GC optimise les allocations/désallocations, en effectuant des traitements par bloc. Si tu crées/détruits 1000 objets, le GC ne fera que quelques allocations/désallocations de mémoire (voir aucune). Dans bien des cas cela peut être plus performant qu'une gestion manuelle...

a- les GC ne concernent que la mémoire et ne touchent pas aux autres ressources. On se retrouve avec un code hétérogène : GC pour la mémoire, dispose-pattern ou autres approches pour les autres ressources

b- Le partage en lui même n'est pas ce qu'il y a de plus important, car c'est facile à réaliser, en C++ du moins.
En revanche les GC (hormis le premier de Java) savent gérer les cycles. Le plus gros avantage des GC, je trouve.

c- C'est un aspect assez connexe au principe des pools. Même en C et C++ on sait faire en détournant les opérations d'allocation. Et ce n'est pas forcément un avantage chez les GC (d'une VM à l'autre, il y a parfois des progres). On gagne certes un temps global d'exécution plus court, mais on peut avoir un effrondrement des perfs à tout moment car l'heure de la collecte est arrivée.

Personnellement je préfère me concentrer sur le code métier de mon application...

100% d'accord!


De mémoire, petit détail que je trouve assez intéressant la VM de .NET permet de distinguer la finalisation des objets, et en particulier de la rendre déterministe, de la collecte de la mémoire. Avec l'arrivée du C++/CLI, on a eu quelques papiers s'auto-congratulant sur un GC qui ne reniait pas le déterminisme et qui marchait main dans la main avec le RAII.

[Médinoc]

Je l'ai déjà posté ailleurs, mais pour moi le GC devrait être un complément du comptage de références:

• Comptage de références : Un objet qui tombe à zéro références est détruit immédiatement (avant que le release() implicite ne retourne).
• GC : Repère et détruit les groupes isolés d'objets se référençant entre eux ("références cycliques") : Tourne en parallèle avec priorité basse, ou bien activé sur demande et quand l'application passe en idle, etc.

Note: Une gestion des "références faibles" peut également être utile pour éviter certaines "fuites" de mémoire.

[mat.M]

J'ai aussi utilisé un GC en C++ dans mon jeune temps et la conclusion fut la même...merdique, inutile, gaspillage de ressources et pire que tout : source de memory leak !!!

Le GC peut être un avantage mais aussi un inconvénient ; la mémoire est fragmentée inutilement donc perte de performances possibles.

Le problème est un peu différent : Java et le GC utilise une zone mémoire nommé heap. Par défaut elle vaut 2 Mo et ne peut utiliser au maximum que 64 Mo. Si une application utilise plus de 64Mo on obtiendra une exception même si le système d'exploitation possèdent encore plein de mémoire libre (il faut spécifier une taille maximum plus grande au lancement de l'application pour résoudre cela) ! C'est une notion spécifique à Java et non pas au GC.
Du coup si une application doit utiliser beaucoup de données (64 Mo ce n'est pas énorme de nos jours) elle se retrouve vite à l'étroit...

C'est quelque chose que je ne savais pas; quel est l'intérêt de programmer avec un langage qui ne permet pas d'allouer + de 64Mo ?
Comment tu fais si par exemple tu veux faire du traitement d'image sur des grosses images ?
Faut-il se cantonner aux API toutes faites du SDK de la JVM ( io.graphics ) ?

[adiGuba]

C'est quelque chose que je ne savais pas; quel est l'intérêt de programmer avec un langage qui ne permet pas d'allouer + de 64Mo ?
Comment tu fais si par exemple tu veux faire du traitement d'image sur des grosses images ?

C'est la valeur maximum par défaut ! Tu peux très simplement augmenter cette valeur avec l'option -Xmx de java lorsque tu lances ton application...

a++

[mat.M]

ok merci du renseignement

[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 ...

[alex_pi]

Réchauffons ce vieux débats :-)

Ce qui me frappe chez les détracteurs de la notion de Glaneur de Cellules, en particulier deneb, c'est qu'ils se placent dans une situation où la gestion manuelles de la mémoire est possible, et ils disent "regardez, là, je peux gérer ma mémoire à la main". Ce qui, je trouve, n'a pas été assez souligné est que dès que la mémoire peut être géré à la main, elle peut l'être géré par un GC, alors que l'inverse n'est pas vrai ! Le problème de la gestion manuelle de la mémoire, c'est qu'il faut savoir à l'avance quand un objet sera libérable, et ce n'est généralement pas possible (pour ce qui est des magic pointers et autre compteur de références, ce ne sont jamais que des formes faibles et non fiable de GC, donc autant en utiliser un vrai, un qui résiste aux structures cyclique)

deneb nous dit qu'il "suffit" de se contraindre au patern "celui qui alloue libère." Mais existe-t-il la moindre raison valable de se plier à cette discipline en dehors justement de la gestion manuelle de la mémoire ?

Il me semble au contraire qu'il y a plein de bonne raison de ne pas le faire. Dès que l'on désire avoir des structures persistantes par exemple. Et je ne parle pas simplement de l'optimisation d'avoir une String non mutable...
Supposons que j'ai des ensembles de chaines de caractère, codés par des arbres (à la Set dans OCaml pour ceux qui connaissent). Quand j'ajoute une nouvelle chaine, ça ne modifie pas mon ensemble, ça m'en retourne un nouveau, modifié, et l'ancien reste disponible inchangé. Mais évidement, l'implémentation n'est pas naïve et ne recopie pas l'arbre ! Il y a partage de la majorité des branches.
On peut imaginer plein d'utilisation de ce genre de chose. Par exemple, je construis une fois pour toute l'arbre avec l'ensemble des mots de la langue française, et j'ajoute parfois les mots technique informatique, et une autre fois les mots d'argots.
Et quand j'en ai fini avec ma version technique, est ce que je peux m'en débarasser ? Bien sûr que non, puisque la version argotique partage de nombreux mots.
Est ce que la fonction d'ajout d'un mot dans la structure peux savoir quand désallouer ? Évidement non.
Il ne reste plus que la solution GC.

Pour résumer, outre le fait qu'on perd énormément de temps à gérer sa mémoire à la main, avec un risque d'erreur bien plus important (et non, une double désallocation n'entraine malheureusement pas toujours un crash direct..), s'imposer cette forme de gestion limite tout simplement les possibilité de ce qu'il est possible de faire ! Après, je ne dénigre pas le fait que dans certain cas très spécifique, une gestion manuelle de la mémoire peut être indispensable.

Ensuite à la question "pourquoi ne peut-on pas désallouer à la main quand ça nous chante", la réponse est "parce que sinon ça casse tout" ! Si j'ai deux variable a et b qui référencent le même objet, que je le déréférence via a (qui peut alors éventuellement basculer sur null), je fais quoi de b ? Si quelqu'un y accède, c'est le drame. Et dire "le programmeur n'a qu'à faire gaffe", c'est contraire au principe de Java et justement de son modèle de gestion de la mémoire qui est d'apporter une forme de sécurité.

Voilà, j'ai apporté mon petit caillou au tas de pierre :-)

[Médinoc]

Comptes-tu la solution "comptage de références" comme incluse dans la solution "GC" ?

[alex_pi]

Comptes-tu la solution "comptage de références" comme incluse dans la solution "GC" ?

Comme je le dis, je pense que c'est une forme non fiable et lourde de GC. Non fiable à cause des cycles, lourde parce que c'est explicite.

[Médinoc]

En C++ avec les bons pointeurs intelligents, on peut la rendre implicite facilement.
Et pour des types "feuilles" comme les chaînes de carcatères, les risques de cycles sont nuls.