Voici un extrait de ce que que j'ai pu lire sur fr.comp.lang.c++ :
"En fait, ce n'est pas la mémoire qui me tracasse: elle sera de
toute façon libérée par le système d'exploitation. Je pense
plutôt à des fichiers à flusher."
C'est quelque chose que j'entends de plus en plus autour de moi : on s'en fout de libérer la mémoire, de toutes façons le système s'en occupe !
Et si le système ne libère pas correctement ? Et si c'est un service qui tourne longtemps et qu'on ne lui a pas imposé de limites ?
C'est moi qui devient vieux (con) ou quoi ?
Journal La mémoire ? On s'en fout !
27
oct.
2004
# C'est un lachage de troll ?
Posté par Émilien Kia (site web personnel) . Évalué à -5.
Effectivement, si tu parles d'un gros service qui tourne en permanance avec des allocations de dixaines de Mo, je dis pas mais si c'est une chtit programme qui ne fait qu'allouer quelques centaines de Ko, c'est pas critique.
Un jour libre ?
[^] # Re: C'est un lachage de troll ?
Posté par mmMMOoooOMMmm . Évalué à 3.
[^] # Re: C'est un lachage de troll ?
Posté par mmMMOoooOMMmm . Évalué à -1.
[^] # Re: C'est un lachage de troll ?
Posté par gc (site web personnel) . Évalué à 3.
T'as des exemples ? À ma connaissance, on ne peut pas (on peut juste lui demander gentiment de faire un tour mais il ne garantit aucune action concrète).
[^] # Re: C'est un lachage de troll ?
Posté par mmMMOoooOMMmm . Évalué à 1.
En ce qui concerne le gc (pas toi, l'autre), j'ai eu un jour (il y a longtemps maintenant, c'était un vieille VM, genre 1.2.x ou 1.3.x) un problème dans un bean avec des listes chaînées et des gros objets. Cela ne libérait pas assez vite (même avec un set nothing.). J'ai dû faire gaffe à "réutiliser" les objets plutôt que d'en prendre des tout neuf.
[^] # Re: C'est un lachage de troll ?
Posté par Ramso . Évalué à 2.
-Xms256M -Xmx256M
Comme ça la VM ne gonfle pas trop et lance le GC avant qu'il ne soit trop tard, avec le blocage qu'on imagine bien pour notre application qui attend son tour d'exécution. La libération se fera petit à petit, avec des latences de quelques secondes au pire.
[^] # Re: C'est un lachage de troll ?
Posté par mmMMOoooOMMmm . Évalué à 1.
[^] # Re: C'est un lachage de troll ?
Posté par Ramso . Évalué à 2.
[^] # Re: C'est un lachage de troll ?
Posté par gc (site web personnel) . Évalué à 2.
Non. Une critique de Java parce que le contrôle sur le GC est beaucoup trop faible (peut-être pour le laisser optimiser, je ne sais pas).
C'est comme pour ou contre les assert().
Je ne vois absolument pas le rapport ?
un problème dans un bean avec des listes chaînées et des gros objets
Il me semble qu'à une époque le GC de Java ne libérait pas correctement les références circulaires, c'est peut-être ça ou lié à ça.
Moi je parlais en fait du fait qu'en Java :
1. il n'y a pas de destructeur (le truc qui s'appelle finalize n'est pas forcément appelé quand l'objet est détruit, et ne sert donc à rien)
2. on ne peut même pas demander au GC de faire un tour dans les finalize en attente (aucune garantie qu'il finalize les objets qui ne sont plus scopés)
Toi il semble que tu parlais plutôt de ton bug de désallocation.
[^] # Re: C'est un lachage de troll ?
Posté par mmMMOoooOMMmm . Évalué à 1.
Je me suis mal exprimé (comme souvent d'ailleurs). Quand je disais "Ça, par contre, c'était un troll.", c'était quand MOI je disais "on est pas en java où des fois faut forcer le garbage collector à faire son office.". C'était une phrase pour troller, comme celle du genre "C'est comme pour ou contre les assert().".
Cela fait longtemps que je ne fais plus de java, et je ne sais pas trop où en est l'état de l'art. C'est peut-être effectivement un bug de désallocation, mais je ne suis pas assez calé sur le sujet pour infirmer ou confirmer.
[^] # Re: C'est un lachage de troll ?
Posté par calandoa . Évalué à 7.
[^] # Euh ... ???
Posté par mmMMOoooOMMmm . Évalué à 1.
# Ca depend
Posté par ckyl . Évalué à 3.
-> Si il parle de pas s'emmerder a chercher tout ce qui est alloue justement avant d'appeler exit(0) ou quelque chose du genre il a raison
-> Si il parle en general c'est moins top
C'est dans quel thread ?
[^] # Re: Ca depend
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Oui
> il a raison
Oui
C'est comme si tu insistait pour désalouer la mémoire avant d'eteindre ton PC, au cas ou elle soit encore allouée la prochaine fois que tu l'allumes. Les processus, c'est fait entre autres pour ça. Quand le processus termine, toute la mémoire est libérée, point barre.
> C'est dans quel thread ?
http://groups.google.com/groups?dq=&hl=en&lr=&threadm=c(...)
Sauf que le message en question n'est pas encore archivé.
[^] # Mauvais débat.
Posté par Émilien Kia (site web personnel) . Évalué à 3.
Là, je n'ai pas de réponse mais je pense que oui de plus en plus.
Mais la question "Peut-on se permettre de ne pas désalouer la mémoire en fin de programme ?" J'aimerai urler : NON, PAS DE FUITE DE MEMOIRE, c'est crade au possible et ca montre qu'on ne maitrise pas ce que l'on fait.
Un jour libre ?
[^] # Re: Mauvais débat.
Posté par ckyl . Évalué à 0.
Heu comment dire tu sais comment fonctionne les VMs ? :-)
> J'aimerai urler : NON, PAS DE FUITE DE MEMOIRE, c'est crade au possible et ca montre qu'on ne maitrise pas ce que l'on fait.
Ce n'est pas une fuite mémoire. Une fuite c'est que tu perds toutes les references sur la memoire que tu as alloué. La effectivement c'est une erreur de conception et c'est a corriger.
Ne pas liberer la mémoire avant la terminaison de l'execution c'est eclaircir le code et une "optimisation"
if (xxxx)
exit(1);
C'est un tantinet plus propre qu'un
if (xxxx) {
/* 45 lignes pour desallouer toute la memoire allouee */
exit(1);
}
C'est exactement la meme chose et c'est meme plus rapide ! (liberer toutes les vmas d'un processus est un tantinet plus rapide que 47 540 free())
[^] # Re: Mauvais débat.
Posté par mmMMOoooOMMmm . Évalué à 3.
Et puis, son problème à la base c'était de lancer une exception dans un destructeur. On peut penser que :
- soit son code est petit auquel cas c'est un code de test, donc on peut "oublier" de libérer la mémoire, mais c'est certainement du code destiné à être intégré ailleurs et donc, on "risque" d'"oublier" de remettre du code de libération si on commente le exit(),
- soit son code est déjà gros et on est dans la même problématique au moment de commenter le exit() (parce que j'imagine mal le exit() rester en place au final).
Si on passe donc sur l'hypothèse (apparemment acquise) que l'OS réussi à toujours libérer correctement la mémoire, ce qui me chagrine, ce sont les habitudes dangereuses. C'est tout. Et j'ai vraiment l'impression d'être old_School.
[^] # Re: Mauvais débat.
Posté par Florent C. . Évalué à 3.
Ensuite, pour les objets alloués dans main(...) deux cas se présentent :
De toute façon, laisser le système gérer la déallocation mémoire est une mauvaise habitude. Point-barre.
[^] # Re: Mauvais débat.
Posté par ckyl . Évalué à 1.
Je parlais dans le cas ou tu termines l'execution... C'est sur que c'est tres grave le delete manquant dans un espace d'adressage qui va etre detruit dans la seconde :-)
Si ton appli a fait son job apres tu t'en fou le système est la pour ca d'ailleur dans tout les softs que j'ai lu (ok je code en C) j'ai pas croisé souvent de gens qui avaient de bonnes habitudes...
Apres j'ai pas lu le thread de fclc++ et je m'en fou donc je n'ai pas repondu la premiere fois en connaissant le contexte (relire mon post).
[^] # Re: Mauvais débat.
Posté par mmMMOoooOMMmm . Évalué à 1.
Je crois qu'on a comprit la substantifique moëlle et ok, ce n'est pas forcément du code "illégal". Ce que certains (dont je fais partie) tentent de dire c'est l'on prend des mauvaises habitudes même pour du petit code ou du code temporaire.
Et ce n'est pas parce que y'a pas souvent-des-gens-qui-ont-des-bonnes-habitudes qu'il ne faut pas en prendre.
[^] # Re: Mauvais débat.
Posté par Florent C. . Évalué à 3.
Quand on alloue des objets, on en est responsable. Donc on les désalloue quand on ne s'en sert plus. Et si on commence à compter sur le système pour les désallouer à certains moments et pas à d'autres, alors on en vient vite à ce genre de réflexions : "de toute façon j'ai 256Mo de RAM, je peux la pourrir comme je veux, mon système va tout libérer quand je vais quitter". Et ce qui devait arriver arrive, on prend l'habitude de ne plus désallouer du tout.
C'est sur que c'est tres grave le delete manquant dans un espace d'adressage qui va etre detruit dans la seconde :-)
Oui parce que delete ne fait pas que désallouer la mémoire, en appelant le constructeur il peut faire tout un tas de choses assez indispensables. Tu serais content si ton logger, une fois planté, ne fait pas de fflush(logfile), et que donc tu ne puisses pas retrouver l'origine du plantage car les derniers logs n'apparaîtraient pas dans le fichier ? Après tout, le système désalloue la mémoire c'est bien connu.
Et que dire de ceux qui ont l'habitude de coder comme ça (c'est-à-dire comme des porcs n'ayont pas peur des mots) et qui se retrouvent subitement à travailler sur un autre système, qui, lui, ne désalloue pas la mémoire automatiquement ? Je mantiens donc : ne pas désallouer la mémoire est une mauvaise habitude.
[^] # Re: Mauvais débat.
Posté par Cali_Mero . Évalué à 3.
Là, je n'ai pas de réponse mais je pense que oui de plus en plus.
Dans le cas de Linux, je le pense aussi. Mais ca m'étonnerait que tous les noyaux (et à priori tous les systèmes) soient aussi rigoureux avec la mémoire. Laisser paresseusement le système libérer la mémoire réservée par le processus, c'est selon moi prendre un gros risque pour la portabilité de son programme.
Et effectivement, c'est contraire aux bonnes pratiques de développement, même si "ça marche".
# Les pieds dans le troll
Posté par Sisyphe Plâtrier . Évalué à 5.
C'est dans l'air du temps : on peut prendre plus ? Alors pourquoi se limiter ?
Après moi, le déluge.
Quand on ne veut pas s'occuper de (envisager, calculer, maîtriser) la quantité de mémoire utilisée, c'est souvent signe d'un je-m'en-foutisme sur à peu près tout, à commencer par les algos !
À moi la vieille garde, les jeunes vieux cons vaincront ! ;-)
[^] # Re: Les pieds dans le troll
Posté par mmMMOoooOMMmm . Évalué à 3.
Ensuite, je suis content je voir que je ne suis peut-être pas le seul (jeune ?) vieux con ! Mais ouais, t'as raison, y'a aussi de plus en plus de je-m'en-foutisme aussi sur les algos.
[^] # Re: Les pieds dans le troll
Posté par Tonton Th (Mastodon) . Évalué à 2.
http://test.vaboofer.com/index.php/ClubDesVieuxCons(...)
# faut voir
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 6.
Ptet que chez toi sur ton ordi, tu peux te passer de désallouer la mémoire..; mais sur un systeme embarqué, sans garbage collector, je donne pas cher de la durée de fonctionnement de ta mémoire...
# OS
Posté par gc (site web personnel) . Évalué à 2.
Euh si c'est le cas tu vas t'en rendre compte très vite et ça risque d'être assez compromis ton affaire.
Il faut partir du fait que l'OS gère correctement son bordel, et si c'est pas le cas il faut qu'il fixe ses bugs, sinon un programme userspace ne peut vraiment rien y faire.
[^] # Re: OS
Posté par Florent C. . Évalué à 3.
Et ne parlons pas des questions de portabilité ....
[^] # Re: OS
Posté par kesako . Évalué à 2.
Et d'ailleurs desalouer soi meme, ce n'est pas toujour valable. exemple : un cgi
Avec les cgi on cherche generalement a ce qu'il soient le plus rapide possible et qu'il chargent le moins la machine.
D'un cote c'est propre de desalouer soi-meme tout ce qu'on a alloué mais c'est long (en codage et en execution), de l'autre ca va bien plus vite que le systeme efface tout d'un coup lorsque le cgi meurt.
Mais en general quand on a des problemes de vitesse sur un serveur web , on rend les cgi permanents (fastcgi , ... ) et alors on a interet a etre propre sinon gare au leaks.
[^] # Re: OS
Posté par Florent C. . Évalué à 1.
N'importe quoi ! Vaut mieux lire ça que d'être aveugle ! J'espère que tu n'auras jamais à travailler sur un système embarqué ou un jeu vidéo ... ou une console de jeux vidéos ... Et j'espère que tu ne diras jamais une ânerie pareille à ton patron ...
[^] # Re: OS
Posté par kesako . Évalué à 4.
On dirait que pour toi , l'informatique ca se resume à l'embarqué et les jeux ...
On ne parle tout simplement pas de la meme chose.
Je suis présentement responsable du dev et de la maintenance d'une bonne dizaine de serveurs en c et c++ qui doivent encaisser 50 à 120 requetes par seconde , 24h/24 7j/7 ( 10 millions de requetes par jour pour le plus chargé) . J'estime donc savoir ce que c'est que la gestion memoire.
[^] # Re: OS
Posté par Florent C. . Évalué à 5.
Pas du tout, mais il faut en prendre compte pour ne pas prendre de mauvaises habitudes.
On ne parle tout simplement pas de la meme chose.
On dirait effectivement, toi tu parles d'un cas particulier où la performance est tellement critique que la gestion de la mémoire doit être laissée à l'OS ou la VM. Moi je parle du cas général, qui est quand même bien plus fréquent que le tiens.
C'est l'éternel compromis entre la performance et la stabilité. Dans mon expérience, et même dans les cas où la performance était critique (les jeux vidéos tiens), eh bien la stabilité a toujours primé.
[^] # Re: OS
Posté par mmMMOoooOMMmm . Évalué à 1.
[...]
...et alors on a interet a etre propre sinon gare au leaks.
C'est pas un peu contradictoire ? Ou alors on fait celui qui est contre mais qui en fait est pour ?
[^] # Re: OS
Posté par ckyl . Évalué à 3.
Le "il faut pas le faire *jamais" est aussi stupide que le mec qui ne comprend pas qu'il fait mal pour moi. C'est a toi de savoir ou c'est important et ou ca l'est pas. Tu _maitrises_ ton code, son environement et les parametres que tu souhaites optimiser et tu codes en fonction de ca. Evidement tu codes pas de la même manière si tu bosses sur de l'embarqué sur un proc sans MMU, que lorsque tu ecris un filtre UNIX, ou une usine a gaz de 10 000 000 de lignes de code !
Note: personne n'a contesté jusque la que perdre les references sur de la mémoire allouée était une erreur monstrueuse !
[^] # Re: OS
Posté par mmMMOoooOMMmm . Évalué à 1.
Un brin énervé ? :-)
Le "il faut pas le faire *jamais" est aussi stupide que [...]
Je suis d'accord sur le fait que "jamais" est trop souvent employé par des pseudo-règles-absolues-qui-tuent, mais je ne pensais pas que c'était une pratique (ma foi) plus répandue que je ne le pensais (la non-libération sciente de la mémoire) pour ces cas là (ne pas s'emmerder a faire des liberations que l'on sait ne servir a rien).
Je pense que j'arrive à comprendre ce qui motive cela. Mais après tous ces posts, je me sens vraiment comme un vieux con. Attention, j'ai bien dit moi et pas les autres, alors pas prendre la mouche, hein !
[^] # Re: OS
Posté par ckyl . Évalué à 2.
Si tu codes en objet c'est normal, effectivement la construction des objets et l'archi globale des applications fait que tu es beaucoup plus carré de ce coté la.
Si tu regardes du cote du C (puisque c'est principalement lui qui pose problème) j'ai jamais vu un devel ecrire "propre". Si tu fais un valgrind sur les applis tu verras qu'il n'y a pas de leaks simplement des warnings "Memoire encore referencee mais non liberee" par ce que ca valait pas le coup de saloper le soft de code inutile. La ou c'est propre dans des destructeurs et se fait en 80 caracteres en P0O; en C tu auras souvent un pavé de 50 lignes pour reussir a terminer proprement, donc on ne fait que ce qui est necessaire et en utilisant atexit() par exemple.
Genre tu ecris un filtre qui construit un arbre a partir de stdin et qui en fait XXX sur stdout. 99% des devels ne vont pas libérer la mémoire, il leur suffirait de faire un parcours recursif s'il y avait besoin mais tant que le cas special ne se presente pas.... Si le même devel est en train d'écrire une lib qui s'interface sur graphviz il fera une fonction pour libérer sa structure.
[^] # Re: OS
Posté par mmMMOoooOMMmm . Évalué à 1.
Ça fait *longtemps* que je n'ai pas codé en C. C'est vrai qu'en objet, c'est peut-être moins bordélique à gérer qu'en C. Et je commence à entrevoir le type d'application (quasiment fonctionnelle sans état, genre filtre comme tu l'as dit auparavant) pour laquelle on peut écrire ce genre de code. Mais c'est clair qu'avec Valring ou Rational Purify, ça doit gueuler ...
# Et les systèmes embarqués dans tout ça ?
Posté par Hugues Hiegel (site web personnel) . Évalué à 2.
A prendre de mauvaises habitudes, il devient tres difficile de s'en défaire.
Et quand on se met a faire du developpement pour l'embarqué par exemple, on comprend pas pourquoi ca marche pas...
Donc l'excuse du "de toutes facons on a tout plein de mémoire en ce moment" est débile, elle est fausse dans plein de cas. Et entre profiter de la mémoire dispo pour faire des goritudes ou profiter de la mémoire pour gérer de gros flux de données et avoir un systeme stable... ou tout simplement l'économiser pour se permettre d'en acheter moins, ya qu'un pas à faire.
On programme proprement ou on ne programme pas, c'est tout ce que j'ai à dire.
[^] # Re: Et les systèmes embarqués dans tout ça ?
Posté par imalip . Évalué à 2.
Ben si c'est vrai. Regarde aujourd'hui tu peux pas trouver un PC avec moins de 256 Mo de RAM. Donc t'es clairement tranquile. Et encore c'est sur des machines d'entree de gamme, hein . Pour peux que tu aies une machine decente, tu as facile un Giga, donc pourquoi s'en faire ?
Regis (jeune vieux con de 25 ans qui prend plaisir a bosser sur des systemes avec 750 ko de memoire)
[^] # Re: Et les systèmes embarqués dans tout ça ?
Posté par mmMMOoooOMMmm . Évalué à 2.
2 minutes avant le crash ?
1 heure avant le crash ?
Un crash en validation ?
Un crash en production ?
[^] # Re: Et les systèmes embarqués dans tout ça ?
Posté par Hugues Hiegel (site web personnel) . Évalué à 4.
Quand j'entends parler de légendes geek de machines qui auraient tourné pendant XX années dans l'oubli le plus total, et sans jamais planter... Je me demande ce qu'il en serait des machines avec les logiciels actuels.
Faut bien qu'on puisse raconter des légendes informaticiennes à nos enfants :-)
Tout ça pour dire que mal coder, c'est ne pas voir plus loin que le bout de son nez et n'avoir rien compris au déploiement d'un logiciel. C'est pas parce qu'un projet mal codé fonctionne en validation qu'il fonctionnera aussi bien en production.
Si on en revient au sujet de base qui est que "de toutes façons l'OS libère lui même la mémoire", quid d'une application qui forke et ne termine jamais ? (un exemple à la con, certes, mais bien représentatif du problème de fond).
[^] # Re: Et les systèmes embarqués dans tout ça ?
Posté par imalip . Évalué à 5.
Commentaire un peu plus serieux que le precendent pour dire que c'est un peu le probleme aujourd'hui. Ca coute moins cher et ca prend moins de temps de developper comme un goret et acheter plus de memoire et une machine plus puissante que de faire du devel aux petits oignons pour tenir compte de contraintes de cout materiel/performance/encombrement/consomation.
Maintenant il faut aller vers l'embarque ou le tres bas niveau pour retrouver cette notion prise en compte. Et encore, quand je vois un telephone mobile qui a besoin de 32 Mo de flash pour stocker le systeme, j'ai mal, compare a un chassis de F1 dont la gestion complete tient dans 1Mo...
[^] # Re: Et les systèmes embarqués dans tout ça ?
Posté par Hugues Hiegel (site web personnel) . Évalué à 2.
La différence, c'est que pour le téléphone, tu as besoin de stocker des photos, des sons et autres conneries qui prennent de la place... et sont totalement inutiles dans le cas d'une F1.
Cependant je comprends bien ce que tu veux dire ;-)
D'ailleurs, c'est là tout l'intérêt des LL sur les solutions proprio pour l'embarqué : on a un bien meilleur contrôle sur l'espace flash occupé par l'OS, et on peut donc l'adapter à nos petits ognions.
Et qui dit LL dit logiciel développé proprement, autant respecter cette politique, non ? :-)
# concrètement ?
Posté par Krunch (site web personnel) . Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: concrètement ?
Posté par ckyl . Évalué à 3.
Ca n'a rien a voir. La recuperation de la mémoire ne depend pas du runtime du C mais du noyau. Quand un processus est créé par le noyau il créer un nouvel espace d'adressage pour le processus, appel le point d'entrer du programme via le loader (le point d'entré n'est pas le main en réalité y'a du code avant) qui lui même appelera main() si tu as un programme en C.
De même quand ton processus est detruit le tu sors du main(), il y a encore du code qui s'execute dont tu n'as pas connaissance et enfin l'ordre est donné au noyau de détruire le processus et au passage son espace d'adressage.
Tout les OS "modernes" courant reposent plus ou moins sur ce principe. Et tout le support est fournit pas le processeur pour y arriver facilement. Le fait que ton programme ou ton runtime C libere la mémoire que lui a attribue le noyau n'a rien a voir, ce sont deux concepts différents (cf dans beaucoup d'OS le tas ne peut que grossir même si tu free() toute ta mémoire...)
Donc pour trouver un système qui ne libère pas la mémoire il faut au choix
- trouver un noyau avec un VM completement buggé (mais ca devient grave !)
- peut etre chercher du cote des systemes pour les processeurs sans MMU
- avec MMU dans l'embarqué mais meme la ca m'étonnerait
- En regardant du cote de windows 9x et OS 7..8..9 on doit pouvoir trouver des conditions dans lesquels la mémoire n'est pas libérée mais de toute facon on peut faire a peu pres n'importe quoi :-)
http://developer.apple.com/documentation/mac/Memory/Memory-2.html(...) C'est rigolo de voir l'état de la gestion mémoire d'OS 7
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.