Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous

Identifiant
Mot de passe

Mot de passe oublié ?

Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Débat langages : Pour ou contre le Garbage Collector ?

Le 2 août 2006 à 10:55, par deneb

481 commentaires

19PARTAGES

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 !!!

Une erreur dans cette actualité ? Signalez-nous-la !

Votre nom : Votre e-mail :

Décrivez l'erreur que vous souhaitez porter à notre connaissance :

481 commentaires

Commenter Signaler un problème

deneb

Nouveau membre du Club

Le 02/08/2006 à 13:43

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.

deneb

Nouveau membre du Club

Le 02/08/2006 à 20:37

C'est vrai que le GC de Java est bien écrit et je veux bien admettre que pour certains il facilite la tâche....pour créer d'autres problèmes

Pour ce qui est des perfs meilleurs par contre, c'est pas avec ton exemple que tu va me convaincre. Allouer un tableau à chaque tour d'une boucle c'est assez marrant...avec un new Object[1000][1024] ça marche plus.

Ce que je regrette c'est :
1 : qu'il déresponsabilise les développeurs qui ne gerent plus du tout leur mémoire...ce qui va même jusqu'à leur faire oublier qu'elle est limitée.
2 : dans certains types d'application (et pas de bol on est pile dedans puisqu'on développe un serveur d'appli) un GC qui bosse quand il veut et bouffe du CPU en même temps pendant que les requêtes clients...c'est pas acceptable.

Bref ce que je voudrais moi, c'est une option no-gc...histoire que ceux qui veulent se palucher la gestion à la main puissent le faire.

divxdede

Membre éclairé

Le 02/08/2006 à 23:41

Alors je vais faire une peu de "dévanalyse" (joli le mot ^^)

Le Garbage Collector est un résultat de l'évolution du "développement".

Il y a 15 ans on devaient apprendre comment "swapper" le contenu de deux variables sans utiliser une troisième afin d'économiser au mieux l'utilisation de nos registres quand on développait en assembleur.

Nous avons eu droit ensuite à dés langages de plus haut niveau tel que le C. A cette époque les pro-assembleurs se targait de la mauvaise gestion mémoire / registres des programmes compilés en C

Quelques années plus tard, les languages POO sont apparus dont nottament Java. En plus des nouvelles méthodologies de conception, ces languages nous ont fait rentré dans une ère ou des APIs extremement riches ont elevés le niveau des développements.

Aujourd'ui on éleve encore un cranc ce niveau avec l'utilisation de ce qu'on appelle les "MiddleWare" (J2EE & Co).

L'ultime but de ces évolutions: Limiter la couverture de dévelopement aux parties métier uniquemement. Tout le reste doit être à la charge du language, outils, serveur et autres joyeuseries.

Le Garbage Collector se positionne trés bien dans cette optique et de ce fait il est trés bénefique. Oui les nostalgiques diront "Mais quand je manipule mes pointeurs, je sais quand je dois liberer mes allocations mémoire !! ".

Certe mais séparer le "system" du "metier" va dans le sens d'un code plus robuste et maintenable.

Alors un GRAND OUI au Garbage Collector.

PS: On pourrait par exemple faire la comparaison avec Hibernate qui gére la persistence à notre place. Ce qui en bon middleware nous permet de nous préoccuper des données avant tout (la persistence n'étant que de la technique). Certains diront toujours "oui mais en C je gére mes flushs au bon moment..." Ok, mais c'est le passé.......

deneb

Nouveau membre du Club

Le 03/08/2006 à 9:10

Envoyé par divxdede

PS: On pourrait par exemple faire la comparaison avec Hibernate qui gére la persistence à notre place. Ce qui en bon middleware nous permet de nous préoccuper des données avant tout (la persistence n'étant que de la technique). Certains diront toujours "oui mais en C je gére mes flushs au bon moment..." Ok, mais c'est le passé.......

La comparaison avec Hibernate n'est pas du tout un argument pour le GC, bien au contraire.

Hibernate rajoute certes une couche très abstraite entre les services métier et la JDBC, mais le travail qu'il réalise est énorme, tout autant que le temps de développement qu'il fait gagner. En contrepartie, il consomme un peu de ressources. Admettons qu'il bouffe 10%, je dois acheter une machine 10% plus puissante en contrepartie, je rajoute donc généreusement 300€ sur la facture. 300€ c'est le coût d'une journée de développement....Est-ce qu'Hibernate m'a fait gagner plus d'un jour de développement sur le projet ? Et oui, largement ! Donc Hibernate me fait économiser de l'argent !

Par contre pour le GC, je vois pas.

Habitués à laisser le GC gérer la mémoire, les devs ne s'en occupent pas, il la gaspillent. Résultat, je dois acheter plus de RAM pour mes serveurs. Perte de fric.
J'ai suffisament écrit de C et C++ pour savoir que la gestion de la mémoire ne prend pas de temps dev. Ou alors vous allez me dire que l'intialisation des variables aussi vous fait perdre du temps ?
Ils passent plus de temps à chercher les fuites que je ne le faisait en C++, encore du fric perdu.
Le GC bouffe des ressources pendant les requetes client, je dois donc encore ralonger pour la puissance de la machine. Ce qui n'impèche en rien les pauses pour collection et les questions des utilisateurs : "je comprend pas, ça marche bien votre truc, mais parfois il y a comme des arrets...on doit être trop nombreux sur le serveur non ?"...

deneb

Nouveau membre du Club

Le 03/08/2006 à 17:28

Bon allez, on peut continuer à parlez philo si vous le souhaitez, mais il est clair que mon option "no-gc" ne pourra jamais exister.
Tout ça à cause d'une autre hérésie de design de Java : les objects "unmutable" comme le très célèbre String.

Pour les amateurs de C++ qui trainent sur ce sujet et qui ne sont pas familiers de ce concept "avancé"

, il s'agit d'un objet dont on est assuré (dans la mesure où il respecte un pattern de construction bien défini) que les valeurs internes ne changeront jamais.
Fort de se principe...on peut se permettre qq hérésies comme ce constructeur de String qui est sensé contruire une nouvelle String avec la valeur d'une autre en argument...
Voila le code (épuré pour ne faire apparaitre que l'essentiel)

Code :

Sélectionner tout

1
2
3
4
5
public String(String original) 
{
[...]
	this.value = original.value;
}

Alors là forcement, si on se permet ce genre de blague, il n'y a plus d'autre solution que de laisser Dieu le Père gérer tout seul la mémoire

deneb

Nouveau membre du Club

Le 04/08/2006 à 9:09

Ahh de la matière

Envoyé par divxdede

Je suis partant

meme si te convaincre n'est pas un but en soi. Chacun a droit a ces opinions !! c'etait simplement que ton précedent post avait une certaine propension au "troll"

Ca en était

Parfois il faut bien dire qq conneries. On peut bien se détentre un peu ici ? (on est pas du coté "help me"

Envoyé par divxdede

On peut penser que le GC sert a gerer la libération mémoire à la place du développeur. Ce qui est FAUX !!
Le GC change la méthode de libération mémoire de la part du développeur.
Au lieu de la liberer explicitement (et donc coder ces algos maisons determinant si un objet peut etre liberé), avec un GC on doit simplement "liberer" un objet en arrettant de le referencer lorsque celui-ci n'est plus nécessaire (pour le referant)

Ok c'est ça que je ne comprend pas! Quels algos fabuleux faut-il inventer ? C'est étrange cette légende selon laquelle il serait compliqué de libérer correctement la mémoire avec un langage sans GC. Moi je ne connais qu'un seul pattern et qui fonctionne à tous les coups (pas qu'en programmation

), celui du responsable : "le créateur est responsable de la vie des ses créations". Et il n'y a jamais le moindre problème. Les seules fois où je me suis demandé si je pouvais bien libérer un object c'est qu'à un moment j'avais codé comme un cochon et que j'étais sorti du schéma.

Envoyé par divxdede

Si le developpeur est rigoureux sur ce dernier point, le GC fera son travail aussi bien qu'un developpeur faisant tout a la main.
D'autant plus que nous avons des outils (WeakReference,SoftReference) pour aider le GC a casser les references cycliques et gerer les caches ou pool.

Aussi bien, mais pas mieux...Tu le souligne toi même, le developpeur Java doit faire preuve d'un grande rigueur s'il ne veut pas voir son heap se réduire comme peau de chagrin. Pour moi cela demande exactement la même attention et le même temps que de gérer proprement ses new/free.

Envoyé par divxdede

Mais alors quel est l'avantage ?
- La liberation par le GC est fiable: il ne liberera pas un objet qu'il ne fallait pas
- Le développeur pilote la gestion mémoire d'une façon plus "confortable" et n'a pas a mettre en oeuvre tout un tas de mécanisme.

La libération par erreur d'un objet engendre un bug archi facile à repérer puiqu'on a droit généralement à un plantage violent. Un test = bug identifié.
A l'inverse une Map qui accumule des références indésirables, ça ne se voit pas. C'est même le genre de sournoiserie qui ne se manifeste qu'à forte charge quand tous les clients sont connectés...
Je préfère de loin le premier cas.
Ensuite ce que tu appelle du confort est pour moi une incitation à une gestion "laxiste"...Et en regardant le code des mes équipes, je crois bien que j'ai un peu raison sur ce point.

Quel sont les inconvenients ?
- On ne contrôle pas le moment de la libération
- Si on ne "casse" pas les réferences inutiles, on se prends des memory leaks
Le dernier incovenient n'est pas trés "recevable" puisqu'il correponds à un developpeur C ne fesant aucun "free()" aprés des "malloc()". Dans ce cas il faut patcher le développeur pour rattraper le tir ^^
Voila ;o)

On en revient au même point...si tu gère bien, le GC fera bien son boulot.
Mais cette bonne gestion demande exactement la même discipline et le même temps qu'une bonne gestion manuelle.
Sauf qu'à la main, le travail est FAIT et on ne voit pas de GC s'inviter de manière intempestive au moment où on a besoin de CPU.

deneb

Nouveau membre du Club

Le 04/08/2006 à 10:07

Envoyé par adiGuba

Ceci est FAUX : le constructeur String(String) est bien un constructeur de copie, et crée bien un nouvel objet totalement différent en mémoire ! D'ailleur c'est indiqué dans la Javadoc : "the newly created string is a copy of the argument string"...

Alors là je crois que tu ferais bien de réviser un peu...
C'est une portion (copiée/collée) d'un constructeur de String pris dans le source du JDK 1.5_07.
C'est d'ailleurs assez logique qu'ils procèdent comme ça, puisque l'objet est immuable...On peut se dire que lorsque tout le monde en aura fini avec ce tableau de char, le GC finira bien par le ramasser.
Désolé, c'est une conception qui ne me satisfait pas.

Envoyé par adiGuba

Enfin, les objets immuables permettent une optimisation de la mémoire en évitant des copies d'objets à tout va, comme cela peut être la cas en C++ pour respecter la règles "le créateur est responsable de la durée de vie des objets"...

Les immuables permettent d'économiser des bouts de chandelles. Essentiellement sur des String. Dans une vrai appli il n'y a AUCUN appel du type : String s = new String("toto"

;
Les chaines sont stockées sur des supports externes (fichiers, bdd,...) et son chargés dans des conteneurs à l'exécution...Dans ce cas je vois pas l'économie.

Envoyé par adiGuba

Ce design pattern te convient peut-être, mais il n'est pas adapté à tous les besoins. Le créateur des objets peut ne pas connaitre la durée de vie exacte des objets, et donc cela complexifie encore les choses...

Je vais pas te citer tous les projets sur lesquel j'ai bossé en plus de 10ans de vie professionnelle (je te fais grâce des 10 précédentes ou je développais en hobbiste, parfois payé). Ce design convient à TOUS les types d'application.
D'ailleurs regarde un peu au tour de toi...en quoi sont écrit 90% des softs que tu utilise ?

Envoyé par adiGuba

Grande rigueur : il ne faut pas exagérer... Il faut juste éviter de multiplier les champs static et d'utiliser 500 attributs dans les objets, alors que la plupart des éléments ne servent que temporairement, ou de les mettres à null lorsqu'on n'en a plus besoin... mais c'est une erreur de programmation, pas un défaut du GC...
C'est la même chose qu'un développeur C qui n'utiliserait que des variables globales...

On tourne en rond...Je te répond que sans GC, il suffit de gérer correctement les new/free. Celui qui réserve libère et puis c'est tout.

Envoyé par adiGuba

C'est peut-être vrai dans le cas où le créateur est responsable de la durée de vie des objets... mais faux dans des cadres plus complexe où tu dois partager des objets...

Je ne vois pas...En matière de complexité un serveur d'application se place sur quelle échelle selon toi ?
Est-ce que le partage d'objets entre plusieurs serveurs te parait une chose compliquée ?
Pas besoin de GC pour faire ça pourtant.

Envoyé par adiGuba

Tu ne compares pas ce qui est comparable... tout simplement parce que la libération par erreur est impossible avec un GC !
Le problème de la Map avec des références indésirables est plus proche d'un oubli de libération de mémoire !
Si tu conserves une Map avec de nombreux objets indésirables, c'est comme si tu ne faisais pas de free() après tes malloc() : c'est une erreur de programmation !
Et dans ces deux cas, il te faudra surveiller la consommation de mémoire de ton application...
Le GC n'est pas miraculeux : il ne peux pas conserver plus d'objet que sa mémoire ne lui permet... mais personne n'a dit le contraire !

Jamais dit le contraire.
Avec ou sans GC il faut faire son taf de développeur.
Là ou mon point du vue diffère du tien, c'est qu'ayant développé très très longtemps en C, pas mal en C++ et finalement encore plus en Java, je SAIS d'expérience que l'effort demandé dans un cas comme dans l'autre est le même.

adiGuba

Expert éminent sénior

Le 02/08/2006 à 11:05

Envoyé par deneb

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

Envoyé par deneb

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

Nouveau membre du Club

Le 02/08/2006 à 11:37

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

Expert éminent sénior

Le 02/08/2006 à 12:12

Envoyé par 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.

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)

Envoyé par deneb

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

Envoyé par deneb

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

Envoyé par deneb

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 ???

Envoyé par deneb

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++

Commenter Signaler un problème