Developpez.com

Plus de 2 000 forums
et jusqu'à 5 000 nouveaux messages par jour

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

Le , par deneb, Nouveau membre du Club
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 !!!


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de chaplin chaplin - Membre expérimenté http://www.developpez.com
le 29/04/2009 à 18:11
Citation Envoyé par Franck SORIANO
C'est très fréquent en Delphi à cause du "owner pattern".

A la base les applications sont conçus statiquement dans Delphi, pour éviter au développeur de faire les allocations mémoires. Au moment de la conception du programme, l'EDI se charge de faire tout le travail d'instanciation des objets à la place du développeur.

Cependant, pour un fenêtre windows qui va être l'owner de tous les contrôles visuels qu'elle contient, c'est difficilement concevable de détruire la fenêtre sans ses objets. En revanche, il est possible de créer dynamiquement la fenêtre et la libérer en l'a fermant. J'en ai fait l'expérience et ça peut réduire drastiquement la quantité de mémoire nécessaire à l'application.

Depuis Delphi 2006, le gestionnaire de mémoire est Fastmm de Pierre Le Riche, un projet Open Source. Tes explications sont notamment basées sur le fonctionnement de ce gestionnaire de mémoire.

J'ai relevé sur un post cette remarque:
La principale évolution est l'intégration de la bibilothèque FastMM (http://sourceforge.net/projects/fastmm/) dans le projet. Les (ré)allocations mémoires sont optimisées. Le gain est surtout sensible lors de l'importation des grandes bases de données. Le temps de traitement peut être divisé par un facteur 4 dans certains cas.

Si quelqu'un veut l'améliorer, les sources sont disponibles.
Avatar de Franck SORIANO Franck SORIANO - Membre expert http://www.developpez.com
le 29/04/2009 à 19:40
Citation Envoyé par alex_pi  Voir le message
Je dirais que je ne suis pas 100% d'accord
En effet, un GC ne relève ni de la magie ni de la divination, donc si on garde un lien père-> fils et que le père est vivant, le fils ne sera pas récupéré, même s'il ne sera jamais utilisé.

En revanche, le GC aide quand même grandement. En effet (si je ne m'abuse), l'usage de ce "owner pattern" est principalement dans un but de... gestion de la mémoire ! Donc si on remplace la gestion par destruction explicite (je détruis le père, ça détruit toute sa descendance) par une gestion complètement automatique (un GC), plus besoin de ce pattern, et donc le risque est amplement réduit.

Le "owner pattern" est un exemple de cas qui conduit à une libération tardive. Mais il y en à encore beaucoup d'autres. Les plus gros problèmes que j'ai pu rencontrés étaient liés à un gestionnaire de cache où le cache avait été conservé alors qu'on n'en avait plus l'utilité. Il est toujours référencé dans le gestionnaire de caches, donc ce n'est pas un leak. Sauf que je perdais quelques centaines de Mo, avec une tendance à l'aggravation...

Citation Envoyé par chaplin  Voir le message
A la base les applications sont conçus statiquement dans Delphi, pour éviter au développeur de faire les allocations mémoires. Au moment de la conception du programme, l'EDI se charge de faire tout le travail d'instanciation des objets à la place du développeur.

Ce qui est encore pire, car on alloue alors automatiquement beaucoup de ressources pour traiter des cas de figure qui seront rencontrés dans peut-être 1% des cas...
C'était la philosophie du RAD dans Delphi. Ca fonctionne pour les petites applis. Mais ce n'est pas utilisable de cette façon à grande échelle.

Depuis Delphi 2006, le gestionnaire de mémoire est Fastmm de Pierre Le Riche, un projet Open Source. Tes explications sont notamment basées sur le fonctionnement de ce gestionnaire de mémoire.

Pour ce qui concerne la détection des memory leak, oui complètement.

Pour le reste, j'ai présenté les problèmes qu'on rencontre dans toute gestion de la mémoire.
FastMM fait d'ailleurs un très bon travail, en contournant plus ou moins ces problèmes avec une triple stratégie :
- Pour les allocations de petite taille, il définit des pools d'allocation pré-allouées. De cette façon, les petites allocations peuvent être très rapides et très nombreuses. Chaque pool est dédiié aux allocations d'une certaine taille, ce qui facilite le recyclage des blocs libérés et ainsi limite la fragmentation.
- Pour les allocations de grande taille, si j'ai bien compris, elles sont effectuées directement auprès de l'OS.
- Entre les deux, pour les blocs de taille moyenne j'imagine qu'il doit utiliser une gestion plus traditionnelle de la mémoire avec une liste chaînée des blocs libres.

Le tout, avec un système de promotion qui permet de recycler les blocs mémoires en les faisant passer d'un rôle à un autre.
Avatar de Garulfo Garulfo - Inactif http://www.developpez.com
le 29/04/2009 à 20:12
Citation Envoyé par Franck SORIANO  Voir le message
Tout simplement parce que lorsque tu fais un New, tu n'es pas en contact direct avec les fonctions d'allocation mémoire de l'OS.[...]

J'ai l'impression que tu n'as pas compris ma remarque... ton intervention sous entendait qu'il n'y a pas plus de problème en général sans GC. Or, les statistiques établies prouvent le contraire (cf. les travaux de Boehm) : les fuites mémoires sont une des deux erreurs les plus communes.

En fait, c'était vrai en 1998... depuis ça a probablement du diminuer vu que les langages à GC sont de plus en plus présent.

Je ne soutiens pas le GC coute que coute, ce n'est qu'un outil de plus avec ses forces et ses faiblesses. Mais il faut lui reconnaitre son point fort : il évite les fuites mémoires.

Au passage, je partage la définition de el_slapper sur les fuites mémoires. C'est donc plus qu'un gaspillage temporaire mais un gaspillage permanent. Le GC ne permet pas de s'affranchir du gaspillage temporaire et un humain pourrait faire mieux qu'un GC. Mais le GC ne fait pas — enfin s'il n'est pas lui même buggé — de fuite permanente, alors que les humains en font, même les bons ! C'est ça le problème.
Avatar de chaplin chaplin - Membre expérimenté http://www.developpez.com
le 29/04/2009 à 20:38
Citation Envoyé par Franck SORIANO
Citation:
Envoyé par chaplin
A la base les applications sont conçus statiquement dans Delphi, pour éviter au développeur de faire les allocations mémoires. Au moment de la conception du programme, l'EDI se charge de faire tout le travail d'instanciation des objets à la place du développeur.

Ce qui est encore pire, car on alloue alors automatiquement beaucoup de ressources pour traiter des cas de figure qui seront rencontrés dans peut-être 1% des cas...
C'était la philosophie du RAD dans Delphi. Ca fonctionne pour les petites applis. Mais ce n'est pas utilisable de cette façon à grande échelle.


Pour des architectures Client/Serveur ou N-tiers, c'est une notion élémentaire à connaître avec ou sans GC puisqu'en .NET tu peux utiliser les instructions Using et Dispose pour forcer la libération de l'objet.
Avatar de Matthieu Brucher Matthieu Brucher - Rédacteur http://www.developpez.com
le 29/04/2009 à 20:39
Citation Envoyé par Garulfo  Voir le message
Mais le GC ne fait pas — enfin s'il n'est pas lui même buggé — de fuite permanente, alors que les humains en font, même les bons ! C'est ça le problème.

Les GC modernes, oui. Mais les GC d'ancienne génération ne peuvent pas libérer les cycles, par exemple.
Avatar de Franck SORIANO Franck SORIANO - Membre expert http://www.developpez.com
le 29/04/2009 à 20:50
Citation Envoyé par Garulfo  Voir le message
J'ai l'impression que tu n'as pas compris ma remarque... ton intervention sous entendait qu'il n'y a pas plus de problème en général sans GC. Or, les statistiques établies prouvent le contraire (cf. les travaux de Boehm) : les fuites mémoires sont une des deux erreurs les plus communes.

En effet. Je voulais surtout souligner le fait qu'on reproche au GC de ne pas libérer immédiatement la mémoire, alors qu'avec une gestion manuelle de la mémoire, ce n'est pas mieux. Et très souvent c'est même pire.

Citation Envoyé par chaplin
puisqu'en .NET tu peux utiliser les instructions Using et Dispose pour forcer la libération de l'objet.

Heu... pour autant que je sache using et dispose ne force pas la libération de l'objet !
Dispose sert à implementer le dispose-pattern afin de libérer les ressources autre que la mémoire utilisée par un objet.
Using est un mécanisme bien pratique pour s'assurer que le Dispose sera bien appelé dès qu'on sort de la porté de l'objet.
En revanche, dans tous les cas, la mémoire ne sera libérée (et le destructeur ne sera appelé) que lors de la prochaine collecte... après tout dépend de ce qu'on entend par "libération de l'objet".
Avatar de souviron34 souviron34 - Expert éminent sénior http://www.developpez.com
le 30/04/2009 à 8:53
Citation Envoyé par Franck SORIANO  Voir le message
En effet. Je voulais surtout souligner le fait qu'on reproche au GC de ne pas libérer immédiatement la mémoire, alors qu'avec une gestion manuelle de la mémoire, ce n'est pas mieux. Et très souvent c'est même pire.

disons que je pense profondément que cela vient d'une méconnaissance (lacune d'enseignement ?) du fait qu'une instruction free ne libère rien réellement, et de l'explication y afférent..
Avatar de chaplin chaplin - Membre expérimenté http://www.developpez.com
le 30/04/2009 à 10:23
Implementing a Dispose Method

The pattern for disposing an object, referred to as a dispose pattern, imposes order on the lifetime of an object.

A type's Disposemethod should release all the resources that it owns. It should also release all resources owned by its base types by calling its parent type's Dispose method. The parent type's Dispose method should release all resources that it owns and in turn call its parent type's Dispose method, propagating this pattern through the hierarchy of base types. To help ensure that resources are always cleaned up appropriately, a Dispose method should be callable multiple times without throwing an exception.

There is no performance benefit in implementing the Dispose method on types that use only managed resources (such as arrays) because they are automatically reclaimed by the garbage collector. Use the Dispose method primarily on managed objects that use native resources and on COM objects that are exposed to the .NET Framework. Managed objects that use native resources (such as the FileStream class) implement the IDisposable interface.

Mais, le dispose pattern de .NET est ressemblant au "Owner pattern" de Delphi, même si les buts sont différents.

Si un gestionnaire de mémoire permet de gagner en performance sur une application, la logique est d'utiliser les recommandations faites dans sa documentation pour arriver aux buts. C'est sûr qu'un moteur mal règlé sera moins efficace, et c'est valable pour n'importe quel outil de développement.
Avatar de Garulfo Garulfo - Inactif http://www.developpez.com
le 30/04/2009 à 19:46
Citation Envoyé par Matthieu Brucher  Voir le message
Les GC modernes, oui. Mais les GC d'ancienne génération ne peuvent pas libérer les cycles, par exemple.

Mais qui s'intéresse à l'ancienne génération ?
Si on regarde le C++ des anciennes générations ce n'est pas glorieux. Mais aujourd'hui on dispose des smart pointers. Comme je l'ai dit je ne suis pas pour ou contre un GC. S'il est disponible je suis content de l'utiliser à peu près tout le temps. Mais je côtoie aussi beaucoup de scientifique qui utilise des HPC et je sais qu'alors il faut parfois contrôler la gestion de mémoire. Ce qui ne fait que prouver qu'il reste beaucoup de recherche à faire ^_^
Avatar de Oompa Oompa - Membre à l'essai http://www.developpez.com
le 23/11/2010 à 15:40
Désolé de réalimenté un vieux débat, je voudrai juste savoir combien peut peser un GC en mémoire?
Avatar de sinok sinok - Modérateur http://www.developpez.com
le 23/11/2010 à 16:42
Réponse terre à terre: un GC en lui même ne tant que ça en mémoire. Vu que ce sont les objets stockés en mémoire qui prennent de la place .

Un GC a avant tout un cout processeur qui est proportionnellement lié au nombre d'objets créés/stockés et à leur durée de vie.
Offres d'emploi IT
Chef de projets informatiques amoa
GECINA - Ile de France - Paris (75000)
Assistant chef de projet
BVA - Ile de France - Boulogne-Billancourt (92100)
Ingénieur développement java j2ee h/f
BULL FR - Rhône Alpes - Lyon (69000)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique C