Forum Linux.noyau pourquoi je dois faire un free() alors que le noyau libere la mémoire à la fin de mon processus

Posté par . Licence CC by-sa.
Tags : aucun
3
13
fév.
2019

Bonjour,

je m’intéresse depuis peu au noyau et je tombe sur une incohérence dans ma facon de voir les choses.

Lorsque je lance un programme, c'est le noyau qui va allouer la mémoire pour mon processus. Et quand mon programme est fini, alors le noyau libere la mémoire pour qu'un autre processus puisse l'utilisé. Mais alors est ce que free() a une vrai utilité ?

Merci d'avance pour votre aide

  • # Déjà c'est une bonne pratique

    Posté par . Évalué à 2.

    Ensuite la mémoire de ton processus n'est libérée que lors de l'exit de ton process.
    Pendant tout son temps de fonctionnement il 'occupe' de la mémoire qui n'est plus disponible pour les autres process, si ce n'est pas nécessaire alors autant ne pas le faire.

    La fonction malloc de ton compilateur n'est pas forcément un appel direct au kernel.
    Sur certain compilo et suivant la version, au démarrage une grande quantité (2Mo par exemple) est demandé au kernel (kmalloc), ensuite les appel suivant à malloc travaillent dans ce 'pool' et quand le 'pool' est épuisé une nouvelle quantitée est demandé au kernel et ainsi de suite.
    Cette technique de pré-alloc permet d'éviter un grand nombre d'appel au kernel (ce qui est couteux en termes de performance à cause du changement de contexte d'execution processeur à faire) et pénalisant pour les performances générale du système .
    Avec gcc on peut remplacer la routine malloc de la libc par une autre et certaine implémantation alternative sont assez intéressante à étudier voici un exemple
    http://hoard.org/

    En conclusion, toujours avoir la discipline d'équilibrer malloc/free et une bonne pratique sur PC et est indispensable en embarqué crois moi d’expérience.

    • [^] # Re: Déjà c'est une bonne pratique

      Posté par . Évalué à 3.

      Je ne sais pas si c'était vraiment la question. J'ai l'impression que l'OP demandait si c'était nécessaire de libérer la mémoire à la fin du programme, comme on le voit parfois dans les exemples et tutoriels. Et là, les deux réponses se valent ; c'est une bonne pratique de toujours avoir le réflexe de libérer la mémoire qu'on a allouée, mais en pratique quand il y a un free() avant le return du main, ça ne va pas changer grand chose (est-ce que la mémoire est vraiment libérée ou est-ce que le compilo ne prend pas la liberté de ne rien faire?).

      • [^] # Re: Déjà c'est une bonne pratique

        Posté par (page perso) . Évalué à 7.

        L'autre avantage aussi, si jamais ton programme est modifié ou copié et que les objets ont une durée de vie différente au sein du programme, tu as déjà les instructions pour libérer la mémoire au bon moment. Cela prévient donc les éventuelles fuites car tu as gardé les allocations dans tes modifs mais sans ajouter les libérations de mémoire nécessaires.

    • [^] # Re: Déjà c'est une bonne pratique

      Posté par (page perso) . Évalué à 4.

      une grande quantité (2Mo par exemple) est demandé au kernel (kmalloc),

      kmalloc est une fonction interne au noyau. L'espace utilisateur (la libc dans ce cas ci) demande de la mémoire via mmap ou sbrk.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Pour faire taire valgrind!

    Posté par . Évalué à 2.

    Outre l'argument des bonnes pratiques et du fait que le code pourra être plus facilement réutilisé, je pense que c'est aussi nécessaire pour aider les analyseurs de code (statiques ou à l’exécution) à identifier les fuites mémoires.

  • # merci

    Posté par . Évalué à 1.

    ok j'ai appris ce que je voulais merci beaucoup pour vos réponses

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.