Discussion:Ramasse-miettes (informatique)

Introduction

L'introduction dit :

• Il est légèrement incorrect de parler d'un langage à ramasse-miettes, tout comme il est incorrect de parler d'un langage compilé. Ces caractéristiques sont propres à une implémentation du langage.

C'est vrai et faux à la fois, car la conception du langage tient forcément compte de sa présence ou non.

Note qu'on peut brancher un GC (Boehm-Weiser sur un prorgamme C/C++) si on en a besoin. Comme ces langages ne sont *effectivement* pas prévu pour le ramassage, il existe des cas limites où le GC se comporte 'mal'. Aurélien

Par exemple, on imagine mal Lisp sans gestion automatique de la mémoire. Ce ne serait plus du tout le même langage. --81.57.130.154 30 mai 2004 à 17:15 (CEST)

C'est probablement pourquoi l'adjectif légérement est utilisé, il faudrait sans doute rephraser en quelque chose comme "strictement parlant il est incorrect de ..." (dans le sens de pédantique) phe 13 jun 2004 à 10:33 (CEST)

Cette remarque est idiote - dison hors sujet, je l'ai supprimée. Aurélien

Elle provenait de ta traduction de l'article anglais. Je retraduirais ce qui va bien quand j'aurais le temps phe 14 jun 2004 à 06:40 (CEST)

Je sais :) Mais à l'époque je trouvai ça moyen, et là je trouve ça pire. Je pense pas que ce soit un problème de traduction. Aurélien

---

Ce paragraphe avait été ajouté en tête de l'article:

La gestion manuelle de la mémoire est l'une des sources les plus courantes d'erreur pour un programmeur. Deux types principaux d'erreur peuvent se produire : l'accès à une zone non allouée, ou qui a été libérée, et la non-libération de la mémoire inutilisée (fuites mémoire). Ces erreurs sont parmis les plus difficiles à détecter.

Je l'ai déplacé vers avantages et inconvénients des GC et modifé en:

La gestion manuelle de la mémoire est l'une des sources les plus courantes d'erreur pour un programmeur. Deux types principaux d'erreur peuvent se produire : l'accès à une zone non allouée, ou qui a été libérée, et la non-libération de la mémoire inutilisée (fuites mémoire). Bien que ces erreurs puissent être difficiles à corriger l'utilisation d'outils et de méthodologie approprié permet d'en réduire l'impact, tandis que l'utilisation d'un rammasse-miettes permet de les éliminer complétement.

J'ai laissé la ref à "l'accès à une zone non allouée, ou qui a été libérée," bien que je pense que ce soit orthogonal aux GC. phe 13 jun 2004 à 10:33 (CEST)

---

Références

Dans l'introduction, il y a le paragraphe "Le terme français de ramasse-miettes apparaît vers 1970 dans les communications de Claude Pair aux écoles d'été de l'AFCET3 ainsi qu'à la même époque dans ses cours d'informatique à l'université de Nancy. Il est rapidement adopté les années suivantes par Jean-Claude Derniame (Nancy), Louis Bazerque (Toulouse), Jean Cea (Nice), Jean-Pierre Verjus (Rennes), Claude Hans (Grenoble), Olivier Lecarme (Montréal) et Jacques Arsac (Paris)." Si la première phrase me parait correcte, la deuxième semble être du name dropping, avec une citation de 7 personnes n'étant pas connues sur Wikipedia, avec des liens vers les villes (à la limite, les laboratoires ou université, ça pourrait se comprendre, mais pourquoi les villes ?), tout ça pour illustrer une simple adoption du terme. Je propose de supprimer la 2e phrase. Pol

Persistence d'objet

"Le ramassage de miettes a été conçu pour gérer l'utilisation de la mémoire mais il peut aussi servir à d'autre propos tel que la vérification de type a l'exécution ou la persistance d'objet."

Qu'est-ce que ça veut dire ? C'était dans l'article original ? Aurélien

Je l'ai ajouté. Tout dépend du type de GC utilisé et de sérialisation d'objet que l'on veut, par exemple si on veut sauver un structure de données sur disque on peut à partir du GC connaitre toute les objets atteignables à partir de celui-ci. Le GC peut aussi avoir à sa disposition des informations de types sur les objets permettant de les utiliser pour la verification de type à l'execution ou pour choisir comment effectuer la sauvegarde d'objet sur support persistant. Une meilleur formulation serait "une partie des caractéristiques d'un GC peuvent parfois être utilisé pour implementer ...". L'implémentation du compilatuer Gnu utilise quelque chose de similaire pour gérer la sauvegarde des en-têtes précompilés phe 13 jun 2004 à 21:03 (CEST)

Je veux bien, mais ça devrait plutôt venir à la fin, dans une catégorie applications connexes du ramasse-miettes. C'est sûr que l'atteignabilité sert à mettre en oeuvre de la prévalence ou ce genre de choses, mais j'aimerais qu'on évite le hors-sujet :) Sur l'histoire des types, tu as des liens, des papiers qui parlent de ça ? (ça m'intéresse, jamais entendu parler) Aurélien

Pas retrouver les références au sujet de la vérification de type, je l'ai supprimmer de l'article. J'ai aussi déplacer cette phrase de la section principe vers avantages/inconvénients, tu as raison elle était trés mal placé. Par contre je ne vois pas ou est le hors-sujet, un GC aide a implémenter la persistance en quoi est-ce HS dans le section avantages/inconvénients de GC ? Si on déclare ça HS le reste l'est aussi, ce sont tous des effets de bords de l'utilisation d'un GC phe 14 jun 2004 à 06:40 (CEST)

hmmmm, je ne suis pas sûr de comprendre. Le principe d'atteignabilité sert à la fois pour le GC et la persistence. De là à suggérer que l'algo du GC et de la persistence travaillent main dans la main, il y a un pas. Pour autant que je sache, beaucoup de langages à GC ne fournissent pas "out of the box" la persistence (les lisps, python, perl, ruby, *ml, haskell, etc...). Le rapprochement me paraît excessif. Aurélien

Je pense donc que je vais l'enlever dans pas longtemps, sauf hurlements. Aurélien

---

La dernière partie (avantages et inconvénients) est bien bordélique. Je crois que je vais sortir mon cutter... Aurélien Au fait, qui a placé al remarque sur GC = (atteignabilité || Comptage de référence) au début de l'article ? Aucun sens de la cohérence, hein ? Camarade, si tu veux contribuer utilement, fait en sorte que tes contributions ne *déséquilibrent* pas le sens de l'article existant. Un peu de respect, m**** :))

J'ai relu l'article, si on considére que le comptage de référence n'est pas un GC alors oui ça peu de sens et il faut supprimé cette phrase et clarifié que le comptage de référence n'est pas un GC et peut-être le déplacer dans un article à part.

A part ça oui, la partie avantages/inconvénients est devenu un peu anarchique, l'ajout de contre-argument dans la méme phrase alourdit le propos.

phe 14 jun 2004 à 06:40 (CEST)

Effectivement, le comptage de référence pourrait mériter un article à part. Des spécialistes ?-) Le comptage de ref est mentionné dans l'article original (et le présent) à la fin, pour dire justement que ce n'est pas du vrai ramassage de miettes ; maintenant, il est clair que je ne suis pas un expert, alors ... Aurélien

comprendre

J'ai essayé de comprendre le fonctionnement et l'intérêt du ramasse miette à partir de cet article mais, je le trouve totalement obscur , je programme depuis longtemps et je débute en programmation objet. Je suis persuadée qu' il y a une manière plus simple d'expliquer , il faut vous mettre à la place d'un néophyte. Quel est l'intérêt de faire un tel article s'il ne s'adresse qu'à des spécialistes?

Le passage « Un ramasse-miettes, ou [autres noms] est un [bidule] informatique de gestion automatique de la mémoire. Il est responsable du recyclage de la mémoire préalablement allouée puis inutilisée » n'est pas clair ? Si tu as programmé en C, puis dans quelque langage possédant un ramasse-miette, tu DOIS voir une différence essentielle. jd ❂ 13 mars 2007 à 18:39 (CET)

"Ramasse-miettes" et terminologie

"Ramasse-miettes"

Je ne sais pas ce que vous en pensez, mais personnellement malgré mes années de programmation objet et mes années de cours je n'ai jamais entendu parler de "Ramasse-miettes" mais uniquement de "Garbage Collector". Je ne suis pas contre la francisation des termes lorsque c'est réellement l'usage, mais ici je ne crois pas que ce soit le cas, je trouve ça plutôt un peu ridicule. Il ne faut pas non plus diaboliser systématiquement tout terme sous prétexte qu'il vienne de l'anglais (on dit bien "internet", "week-end", etc.)

J'aime bien le terme ramasse-miettes et je l'ai déjà entendu assez souvent. Pas chez ma boulangère, mais sur de nombreux articles sur « Le Internet ». -- haypo 8 septembre 2007 à 00:26 (CEST)

Pour autant que je sache, mon professeur de thèse Claude Pair, à l'université de Nancy, avait proposé ce terme de "ramasse-miettes" lors d'une école d'été de l'AFCET, quelque temps avant 1970, et ce terme - très parlant - avait été repris par Verjus (Rennes), Bazerque (Toulouse), Bellissant et Lecarme (Grenoble), Derniame (Nancy), Cea (Nice) et Arsac (Paris). 81.53.131.253 (d) 2 janvier 2011 à 00:30 (CET)

Le terme "Ramasse-miettes" est ancien, et semble avoir eu plus de succès que Glaneur de Cellule, pourtant plus astucieux car il préserve l'initiale GC. Bernard Lang (d) 17 septembre 2011 à 01:38 (CEST)

participes présents ... nettoyage vs balayage

Je n'ai pas touché à la terminologie utilisée dans l'article, mais elle me met mal à l'aise. Je n'aime pas trop l'usage des participes présents qui est souvent inélégant en français. Par ailleurs le mark&sweep ne fait pas du nettoyage (?), mais du balayage de la mémoire pour récupérer ce qui est devenu disponible. Il s'ensuit que je préfère parler d'un ramasseur marqueur et balayeur, plutot que marquant et nettoyant. De même je préfère un ramasseur traverseur plutôt que traversant, encore que ma vrai préférence aille à traceur. Idem pour copiant et copieur. Bernard Lang (d) 17 septembre 2011 à 01:38 (CEST)

précis vs exact

Pour la section sur le GC conservatif, il me semble qu'il est préférable de parler de GC précis plutôt que de GC exact. Cela correspond à l'idée que l'algorithme de recherche des objets vivants n'identifie comme vivant aucun objet qui ne le soit pas. Cela correspond justement à ce que l'on appelle la précision dans les algorithmes de recherche d'information : la précision est le rapport du nombre d'objets trouvés effectivement utiles sur le nombre total d'objets trouvés. Le concept complémentaire est rappel (une traduction discutable de l'anglais recall) qui est le rapport du nombre d'objets utiles trouvés sur le nombre total d'objets utiles recherchés. Bien évidemment, pour être correct, un GC doit avoir un rappel égal à 1. Il faut faire attention à la dualité des points de vue : ici on recherche tous les objets vivants, et on considère les autres comme morts, même si le GC peut être perçu comme un outil pour retrouver les objets morts et les récupérer. Bernard Lang (d) 18 septembre 2011 à 12:39 (CEST)

objet vs cellule

Je me demande s'il n'y a pas un risque de confusion quand on utilise le mot objet pour parler des fragments de mémoire gérés par le GC. En effet, le terme est déjà très fortement connoté en programmation et le GC est un concept tout-à-fait indépendant de tout ce que l'on appelle objet. Personnellement, je préfère le mot cellule, moins connoté et plus ancien dans la littérature sur cette question. Bernard Lang (d) 18 septembre 2011 à 12:39 (CEST)

Références

Les choix des références ne sont pas motivés. La première est un classique (parmi bien d'autres). La deuxième est un livre, et ils ne sont pas nombreux (il y en a un en français [|| Gestion dynamique de la mémoire dans les langages de programmation]). Mais quid de la troisième (Siebert). Pourquoi est-elle là ? Bernard Lang (d) 17 septembre 2011 à 02:14 (CEST)

Proposition d'anecdote pour la page d'accueil

Une anecdote fondée sur cet article a été proposée ici (une fois acceptée ou refusée, elle est archivée là). N'hésitez pas à apporter votre avis sur sa pertinence ou sa formulation et à ajouter des sources dans l'article.
Les anecdotes sont destinées à la section « Le Saviez-vous ? » de la page d'accueil de Wikipédia. Elles doivent d'abord être proposées sur la page dédiée.
(ceci est un message automatique du bot GhosterBot le 13 septembre 2022 à 09:15, sans bot flag)