Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 18 sur 18
  1. #1
    Invité de passage
    Inscrit en
    octobre 2012
    Messages
    10
    Détails du profil
    Informations forums :
    Inscription : octobre 2012
    Messages : 10
    Points : 4
    Points
    4

    Par défaut malloc et free incomplet?

    Bonjour,
    je me suis amusé a faire une bête liste chainée et je ne comprends pas pourquoi mon programme prends près de 4 Mo à la fin de l'exécution par rapport au 310 ko de départ.

    Si j'appelle ma fonction plusieurs fois, à la fin mon programme prends environ 4,4Mo

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
     
    #include <stdio.h>
    #include <stdlib.h>
     
    struct pchar
    {
        char caract;
        struct pchar *nextChar;
    }pchar;
     
    typedef struct pchar* tpchar;
     
    void mumuse ()
    {
        tpchar testmem;
        tpchar temp;
        tpchar tete_liste;
        int i;
        printf ("je vais prendre de la memoire\n");
        scanf ("%d", &i );
        testmem = ( tpchar ) malloc ( sizeof ( pchar ));
        tete_liste = testmem;
        for ( i = 0 ; i <= 30000000 ; i++ )
        {
            testmem -> nextChar = ( tpchar ) malloc ( sizeof ( pchar ));
            testmem = testmem -> nextChar;
        }
        testmem -> nextChar = NULL;
        printf ("la mémoire est prise\n");
        scanf ("%d", &i );
        testmem = tete_liste;
        while ( testmem != NULL )
        {
            temp = testmem;
            testmem = testmem -> nextChar;
            free(temp);
        }
        printf ("il reste 3 mo...\n", &i );
        scanf ("%d", &i );
    }
    int main(void)
    {
        int i;
        mumuse ();
        scanf ("%d", &i );
        return 0;
    }

  2. #2
    Membre Expert
    Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    mars 2006
    Messages
    827
    Détails du profil
    Informations personnelles :
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : Industrie

    Informations forums :
    Inscription : mars 2006
    Messages : 827
    Points : 1 145
    Points
    1 145

    Par défaut

    Salut,

    Et testmem lui-même, tu ne fais pas de free dessus?

    A+

    Pfeuh

  3. #3
    Membre confirmé

    Inscrit en
    décembre 2012
    Messages
    50
    Détails du profil
    Informations forums :
    Inscription : décembre 2012
    Messages : 50
    Points : 261
    Points
    261

    Par défaut

    Dans ce programme, la mémoire allouée est correctement libérée. Il n'y a pas de fuite de mémoire ici. Si le programme occupe toujours de l'espace mémoire après avoir utilisé "free", cela provient d'une raison externe au code.

    Pour s'en convaincre, on peut remplacer les appels à "malloc" et "free" par des appels à ces fonctions :
    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    void * malloc_verbeux (int taille)
    {
      void * adresse_memoire;
      adresse_memoire = malloc (taille);
      printf ("mall %p\n", adresse_memoire);
      return adresse_memoire;
    }
     
    void free_verbeux (void * adresse_memoire)
    {
      free (adresse_memoire);
      printf ("free %p\n", adresse_memoire);
    }
    Ainsi, il est facile de s'assurer que les zones mémoires allouées sont bien libérées, du moins tant que le nombre d'allocations ne dépasse pas 5.



    Remarque 1 : Lors de la création d'un nouvel élément de liste, il serait judicieux d'initialiser son pointeur "nextChar" à la valeur "NULL".


    Remarque 2 : Il est inutile de passer l'adresse de la variable "i" en argument à la fonction "printf". Par exemple, cet appel à la ligne 19 :
    Code C :
        printf ("je vais prendre de la memoire\n", &i );
    serait avantageusement remplacé par :
    Code C :
        printf ("je vais prendre de la memoire\n");


    Remarque 3 : Il est recommandé de tester la valeur de retour de la fonction "malloc", afin de s'assurer que l'allocation mémoire s'est bien déroulée. Elle peut en effet échouer si il n'y a plus assez de mémoire libre. Voici un exemple de code :
    Code C :
    1
    2
    3
    4
      int * adresse_memoire;
      adresse_memoire = malloc (sizeof (int));
      if (adresse_memoire == NULL)
        exit(EXIT_FAILURE);


    Remarque 4 : Il est préférable d'utiliser l'une des constantes "EXIT_SUCCESS" ou "EXIT_FAILURE" prédéfinies dans l'entête "stdlib.h" pour désigner la valeur de retour du programme. Autrement dit, dans la fonction "main", il est préférable de remplacer
    par


    Remarque 5 : En langage C, il est préférable d'écrire explicitement les arguments de la fonction "main". Autrement dit, il est préférable de remplacer
    par

  4. #4
    Invité de passage
    Inscrit en
    octobre 2012
    Messages
    10
    Détails du profil
    Informations forums :
    Inscription : octobre 2012
    Messages : 10
    Points : 4
    Points
    4

    Par défaut

    merci pour les dernières remarques, c'est vrai que je n'ai pas fait attention aux détails car ce programme ne me sert à rien, juste a vous poser cette question existentielle de l'utilisation de la mémoire après les free .

    Qui trouvera LA solution ?

  5. #5
    Expert Confirmé Sénior Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2005
    Messages
    23 607
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2005
    Messages : 23 607
    Points : 34 993
    Points
    34 993

    Par défaut

    Si le comportement ne vient pas de malloc(), alors il vient de la plate-forme sur laquelle le programme tourne. Tu dois donc nous préciser l'OS, compilateur, etc.

    Attention au passage, rien ne garantit que la mémoire retournée par malloc() soit initialisée à zéro: Le pointeur nextChar de ton dernier chaînon peut contenir n'importe quoi!
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  6. #6
    Membre éprouvé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    mai 2011
    Messages
    254
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : mai 2011
    Messages : 254
    Points : 444
    Points
    444

    Par défaut

    Arrêtez de vous prendre la tête! Les librairies de base sont fiables (bien que j'en ai également douté)

    J'ai vu pas mal de questions au sujet de malloc / free / printf, et il s'avère que le problème vient toujours de l'application, et non de la librairie.

    Arrêtez de croire que parce que votre application a un problème, il vient de la librairie!

  7. #7
    Invité de passage
    Inscrit en
    octobre 2012
    Messages
    10
    Détails du profil
    Informations forums :
    Inscription : octobre 2012
    Messages : 10
    Points : 4
    Points
    4

    Par défaut

    je tourne sur codeblocks, mon compilateur c'est gcc sur mon os: win7
    c'est vrai que je n'ai pas mis à NULL le dernier pointage sur le chaînon suivant, la mise à jour est faite et non cela ne résout pas le problème.

    Je suis passé sous linux (ubuntu 12.10) pour étudier le comportement du programme, je suis toujours sur codeblocks et mon compilateur c'est encore gcc. Il est a noté que de base mon programme prends moins de ko. Une fois que je prends de la mémoire je passe à environ 900 Mo au lieu de 500 sous windows, le pire c'est que sous linux la mémoire ne se libère pas. Par contre si je relance plusieurs cette même fonction cela ne bouge pas en mémoire je suis toujours à 900 Mo...
    J'ai essayé de lancer mon programme dans le terminal et non depuis cb et cela n'a rien changé...

    Pour faire simple avez vous déjà vu une liste chainée ne laissant aucune trace en mémoire après avoir fait une multiple allocation? SI oui dans ce cas donnez moi le code car pour l'instant je suis dans l'impasse...

  8. #8
    Expert Confirmé Sénior
    Avatar de Sve@r
    Homme Profil pro Frédéric
    Ingénieur développement logiciels
    Inscrit en
    février 2006
    Messages
    4 148
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric
    Âge : 45
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : février 2006
    Messages : 4 148
    Points : 9 025
    Points
    9 025

    Par défaut

    Salut

    Citation Envoyé par Julien Sanchez Voir le message
    Remarque 1 : Lors de la création d'un nouvel élément de liste, il serait judicieux d'initialiser son pointeur "nextChar" à la valeur "NULL".
    Personnellement je suis pour l'initialisation uniquement nécessaire donc mettre le next à NULL n'est pas vraiment utile puisqu'il sera mis à jour lors de l'insertion de l'élément dans la liste. Mais l'autre école (j'initialise systématiquement comme ça je suis tranquille) se justifie aussi surtout avec la puissance sans cesse accrue de nos machines qui permettent maintenant de se moquer de ce petit gaspillage de temps processeur...

    Citation Envoyé par Julien Sanchez Voir le message
    Remarque 2 : Il est inutile de passer l'adresse de la variable "i" en argument à la fonction "printf". Par exemple, cet appel à la ligne 19 :
    Code C :
        printf ("je vais prendre de la memoire\n", &i );
    serait avantageusement remplacé par :
    Code C :
        printf ("je vais prendre de la memoire\n");
    C'est plus qu'inutile, c'est même carrément une erreur...

    Citation Envoyé par Julien Sanchez Voir le message
    Remarque 3 : Il est recommandé de tester la valeur de retour de la fonction "malloc", afin de s'assurer que l'allocation mémoire s'est bien déroulée. Elle peut en effet échouer si il n'y a plus assez de mémoire libre. Voici un exemple de code :
    Code C :
    1
    2
    3
    4
      int * adresse_memoire;
      adresse_memoire = malloc (sizeof (int));
      if (adresse_memoire == NULL)
        exit(EXIT_FAILURE);
    Il est aussi préférable de ne pas utiliser exit pour quitter brutalement une fonction interne et réserver l'entrée/sortie du programme à la seule fonction main()
    Code C :
    1
    2
    3
    4
      int * adresse_memoire;
      adresse_memoire = malloc (sizeof (int));
      if (adresse_memoire == NULL)
        return NULL;
    Charge à l'appelant de gérer ce NULL et donc de le remonter à son propre appelant ou bien de faire ce qu'il faut...

    Citation Envoyé par Julien Sanchez Voir le message
    Remarque 5 : En langage C, il est préférable d'écrire explicitement les arguments de la fonction "main". Autrement dit, il est préférable de remplacer
    par
    Peut-être que je me trompe mais je pense que c'est en C++ qu'il faut impérativement spécifier le void et que le C ne l'impose pas (même si c'est pas interdit)...

    Citation Envoyé par Médinoc Voir le message
    Attention au passage, rien ne garantit que la mémoire retournée par malloc() soit initialisée à zéro: Le pointeur nextChar de ton dernier chaînon peut contenir n'importe quoi!
    En fait, c'est surtout garantit que la zone allouée n'est pas initialisée...

    Citation Envoyé par callsty Voir le message
    J'ai essayé de lancer mon programme dans le terminal et non depuis cb et cela n'a rien changé...

    Pour faire simple avez vous déjà vu une liste chainée ne laissant aucune trace en mémoire après avoir fait une multiple allocation? SI oui dans ce cas donnez moi le code car pour l'instant je suis dans l'impasse...
    En fait, je pense que la mémoire est gérée comme le fait une bdd. Par exemple, Postgres gère ses tables par des pages qu'il alloue quand il a besoin. Mais quand on supprime des données des tables, il indique simplement que les pages allouées sont dispo pour d'autres données mais ne les libère pas physiquement. Donc la place utilisée par les données insérées puis effacées ensuite reste quand-même utilisée sur le disque. Il est ensuite nécessaire de faire un vacuum pour qu'il retasse les données réelles et libère l'espace libre.
    Et donc peut-être que le free se comporte de la même façon. La mémoire libérée reste allouée au programme lui-même qui pourra donc la réutiliser au malloc suivant. D'ailleurs il existe (sous Windows) des utilitaires sensés scruter les programmes actifs et rendre à l'os ces zones mémoires libérées logiquement mais non physiquement...
    Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
    Tout ce qu'un individu reçoit sans rien faire pour l'obtenir, un autre individu a dû travailler pour le produire sans en tirer profit.
    Tout Pouvoir ne peut distribuer aux uns que ce qu'il a préalablement confisqué à d'autres car on n'accroît pas les biens en les divisant.
    Quand la moitié d'un peuple croit qu'il ne sert à rien de faire des efforts car l'autre moitié les fera pour elle, et quand cette dernière moitié se dit qu'il ne sert à rien d'en faire car ils bénéficieront à d'autres, cela s'appelle le déclin et la fin d'une nation.
    Dr. Adrian Rogers, 1931

  9. #9
    Invité de passage
    Inscrit en
    octobre 2012
    Messages
    10
    Détails du profil
    Informations forums :
    Inscription : octobre 2012
    Messages : 10
    Points : 4
    Points
    4

    Par défaut

    Merci beaucoup pour ta réponse Sve@r,
    Maintenant la vrai interrogation c'est de savoir comment on libère la mémoire physiquement et non logiquement?
    Apparemment c'est vraiment à la charge du système d'exploitation. Si c'est bien le cas je suis tombé dans un problème bien trop complexe a mon niveau je pense.

  10. #10
    Membre confirmé

    Inscrit en
    décembre 2012
    Messages
    50
    Détails du profil
    Informations forums :
    Inscription : décembre 2012
    Messages : 50
    Points : 261
    Points
    261

    Par défaut

    Je viens de le vérifier, le programme écrit par callsty libère correctement toute la mémoire allouée avant de se terminer.

    Je ne peux malheureusement pas me procurer la spécification officielle du langage C auprès de l'organisme ISO car cela coûte environ 200 euros, je trouve cela triste. Cependant j'ai trouvé un brouillon daté de 2005 à cette adresse : www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf. Voici ma traduction de cette spécification de la fonction "free".

    Citation Envoyé par open-std.org

    Synopsis
    Code C :
    1
    2
    #include <stdlib.h>
    void free(void *ptr);
    Description

    La fonction "free" entraîne la désallocation de l'espace pointé par "ptr", c'est-à-dire que l'espace pointé par "ptr" est rendu disponible pour une allocation ultérieure. Si "ptr" est un pointeur nul, aucune action ne se produit. Dans le cas contraire, si l'argument ne correspond pas à un pointeur précédemment retourné par la fonction "calloc", "malloc", ou "realloc", ou si l'espace a été désalloué par un appel à "free" ou "realloc", le comportement est indéfini.

    Valeur de retour

    La fonction "free" ne retourne aucune valeur.
    Il n'est pas spécifié que la fonction "free" doive rendre la zone mémoire "ptr" disponible pour le système d'exploitation. Elle est seulement obligée de la rendre disponible pour une allocation future lors d'un appel à "malloc", "calloc" ou "realloc".

    Je n'en suis pas sûr, mais il me semble donc que si on veut rester conforme au C standard, on ne peut pas obliger le programme à rendre au système d'exploitation de la mémoire allouée via la fonction "malloc". Car il serait possible qu'une implémentation du langage C conforme au standard ait programmé les fonctions "malloc" et "free" de façon à ce qu'elle ne restituent jamais la mémoire non utilisée au système d'exploitation. La seule solution pour libérer la mémoire serait alors de terminer le programme.

  11. #11
    Expert Confirmé Sénior

    Inscrit en
    novembre 2005
    Messages
    5 094
    Détails du profil
    Informations forums :
    Inscription : novembre 2005
    Messages : 5 094
    Points : 5 956
    Points
    5 956

    Par défaut

    Citation Envoyé par Julien Sanchez Voir le message
    Je viens de le vérifier, le programme écrit par callsty libère correctement toute la mémoire allouée avant de se terminer.

    Je ne peux malheureusement pas me procurer la spécification officielle du langage C auprès de l'organisme ISO car cela coûte environ 200 euros, je trouve cela triste.
    $30.00 sur le site de l'ANSI. Mais bon, c'est un débat qu'on a déjà eu combien de fois?

    Sur la question de rendre la mémoire à l'OS.
    1/ Je ne vois pas comment le formuler l'idée dans le cadre de la norme.
    2/ Les problèmes de fragmentation font qu'en pratique les cas où c'est possible sont rares, donc en faire une contrainte serait difficile sans exclure des techniques d'implémentation raisonnables.
    Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.

  12. #12
    Invité de passage
    Inscrit en
    octobre 2012
    Messages
    10
    Détails du profil
    Informations forums :
    Inscription : octobre 2012
    Messages : 10
    Points : 4
    Points
    4

    Par défaut

    Merci pour ta réponse Jean-Marc.Bourget
    Dans ce cas es qu'il y a un langage ou autre extérieur au c qui puisse forcer à rendre la mémoire? Quels sont les techniques d'implémentation?
    Je suis insistant car sur le web je n'ai vu aucune réponses et cela manque cruellement à tout les novices comme moi.

  13. #13
    Membre émérite
    Avatar de Kirilenko
    Homme Profil pro Lucas Pesenti
    Étudiant
    Inscrit en
    décembre 2011
    Messages
    234
    Détails du profil
    Informations personnelles :
    Nom : Homme Lucas Pesenti
    Âge : 17
    Localisation : France, Vaucluse (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2011
    Messages : 234
    Points : 858
    Points
    858

    Par défaut

    Bonjour,

    Citation Envoyé par Julien Sanchez Voir le message
    Je n'en suis pas sûr, mais il me semble donc que si on veut rester conforme au C standard, on ne peut pas obliger le programme à rendre au système d'exploitation de la mémoire allouée via la fonction "malloc". Car il serait possible qu'une implémentation du langage C conforme au standard ait programmé les fonctions "malloc" et "free" de façon à ce qu'elle ne restituent jamais la mémoire non utilisée au système d'exploitation.
    C'est d'ailleurs de cette manière que la plupart des allocateurs mémoires fonctionnent : pour des raisons de performance, la mémoire libérée est rajoutée à la liste maintenue par le système d'allocation afin d'être réutilisée lors d'allocations ultérieures. Lorsqu'on n'en a plus, on agrandit la taille du segment de données (à coup de brk p.ex.). Il me semble étrange (du point de vue du concepteur) de vouloir aller à l'encontre de la stratégie du système d'exploitation), pour le coup. Après tout, c'est un peu son problème.

    Bonne journée.
    Récursivité en C : épidémie ou hérésie ?

    "Pour être un saint dans l'Église de l'Emacs, il faut vivre une vie pure. Il faut se passer de tout logiciel propriétaire. Heureusement, être célibataire n'est pas obligé. C'est donc bien mieux que les autres églises" - Richard Stallman

  14. #14
    Expert Confirmé Sénior

    Inscrit en
    novembre 2005
    Messages
    5 094
    Détails du profil
    Informations forums :
    Inscription : novembre 2005
    Messages : 5 094
    Points : 5 956
    Points
    5 956

    Par défaut

    Citation Envoyé par callsty Voir le message
    Merci pour ta réponse Jean-Marc.Bourget
    Dans ce cas es qu'il y a un langage ou autre extérieur au c qui puisse forcer à rendre la mémoire? Quels sont les techniques d'implémentation?
    Je suis insistant car sur le web je n'ai vu aucune réponses et cela manque cruellement à tout les novices comme moi.
    Si ce que te fournis l'implémentation ne te conviens pas, il te faut taper en dessous et utiliser directement ce que te fournis l'OS (en t'assurant de ne pas interférer avec l'implémentation). Donc utiliser qqch comme mmap sous Unix.

    Le problème est que l'OS gère la mémoire avec une granularité minimale d'une page (valeur typique: 4kb), donc tu va vouloir la découper, et pour la rendre à l'OS il faut t'assurer qu'elle soit complètement inutilisée. C'est un surcoût.

    Note que ce que font certains allocateurs, c'est d'utiliser des techniques différentes suivant la taille demandée, et rendre la mémoire à l'OS pour les grandes tailles d'allocation.
    Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.

  15. #15
    Membre Expert
    Avatar de imperio
    Homme Profil pro
    Étudiant
    Inscrit en
    mai 2010
    Messages
    520
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : mai 2010
    Messages : 520
    Points : 1 025
    Points
    1 025

    Par défaut

    Le problème est que l'OS gère la mémoire avec une granularité minimale d'une page (valeur typique: 4kb), donc tu va vouloir la découper, et pour la rendre à l'OS il faut t'assurer qu'elle soit complètement inutilisée. C'est un surcoût.
    Tout dépend du système en effet. J'ai souvenir que freebsd a une pagesize de 1 octet justement. Dans tous les cas il suffirait de vérifier si l'adresse qu'on vient de free est la dernière et si oui la rendre de nouveau accessible au système. Il me semblait d'ailleurs que c'était géré de cette façon. Je suis un peu étonné. D'ailleurs, je me demande ce que la pagesize change vraiment pour un système d'exploitation. Pourquoi ne pas en faire une de la même taille pour tous ?

  16. #16
    Expert Confirmé Sénior

    Inscrit en
    novembre 2005
    Messages
    5 094
    Détails du profil
    Informations forums :
    Inscription : novembre 2005
    Messages : 5 094
    Points : 5 956
    Points
    5 956

    Par défaut

    Citation Envoyé par imperio Voir le message
    Tout dépend du système en effet. J'ai souvenir que freebsd a une pagesize de 1 octet justement.
    Ça m'étonnerait fortement. C'est plus une caractéristique du processeur que de l'OS

    Dans tous les cas il suffirait de vérifier si l'adresse qu'on vient de free est la dernière et si oui la rendre de nouveau accessible au système.
    Tu es dans l'optique de sbrk, mais il n'y a pas que ça qui est utilisé.
    De plus il te faudrait aussi rendre à l'OS tout ce qui précède et est libre.

    D'ailleurs, je me demande ce que la pagesize change vraiment pour un système d'exploitation. Pourquoi ne pas en faire une de la même taille pour tous ?
    Les OS utilisent ce que les processeurs fournissent.
    Plus elle est faible, plus la taille des structures de données de l'OS utilisées pour gérer une quantité de mémoire est grande et plus il doit faire des opérations pour ce faire. Ça a un coût aussi. La tendance est plutôt à chercher à gérer de grandes pages (ce que les processeurs fournissent depuis un bon moment).
    Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.

  17. #17
    Invité de passage
    Inscrit en
    octobre 2012
    Messages
    10
    Détails du profil
    Informations forums :
    Inscription : octobre 2012
    Messages : 10
    Points : 4
    Points
    4

    Par défaut

    Dans tous les cas il suffirait de vérifier si l'adresse qu'on vient de free est la dernière et si oui la rendre de nouveau accessible au système.
    Tu es dans l'optique de sbrk, mais il n'y a pas que ça qui est utilisé.
    De plus il te faudrait aussi rendre à l'OS tout ce qui précède et est libre.
    C'est intéressant comme idée mais j'ai du mal à voir comment cela fonctionne. Es ce qu'il faut refaire une ré-allocation complète du programme dans la mémoire et supprimer la précédente ?

  18. #18
    Membre confirmé

    Inscrit en
    décembre 2012
    Messages
    50
    Détails du profil
    Informations forums :
    Inscription : décembre 2012
    Messages : 50
    Points : 261
    Points
    261

    Par défaut

    Comme l'a suggéré Jean-Marc.Bourguet, si la façon dont malloc et free sont programmées ne convient pas, il est possible de les réécrire.

    Quand on ne sait pas par où commencer, la première chose à faire est de lire leur code source et essayer de le comprendre. Pour le système d'exploitation GNU/Linux, le code source de malloc et free se trouve sur le site de la GNU C Library. On peut le lire en ligne sur le dépôt git de la glibc. On peut accéder directement au fichier source "malloc.c".

    Pour écrire sa propre version de malloc et free sous GNU/Linux, il est utile de lire la description des fonctions mmap et munmap, ainsi que la documentation sur la gestion de la mémoire avec la glibc.


    Une solution alternative serait de scinder le programme final en deux petits programmes. Le premier petit programme étant un gros consommateur de mémoire, alors que le second n'en consomme que très peu et met beaucoup de temps à s'exécuter. On commencerait par démarrer le premier petit programme, puis, une fois que celui-ci à terminé son travail, il lance le second, en lui passant en argument les résultats dont il a besoin. Voir à ce sujet la documentation de la glibc sur les processus, les descriptions des fonctions execve et system, et la communication inter-processus.


    Un conseil : ne pas utiliser de telles techniques d'optimisation. Surtout quand on débute.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •