• [^] # Re: malloc() et realloc() sous linux

    Posté par . En réponse au journal realloc. Évalué à 4.

    Au final sous linux il y a à priori une seule façon d'avoir ces fonctions qui retournent NULL, c'est en cas de fragmentation trop importante de l'espace d'adressage du processus qui rendrait impossible une allocation de la taille souhaitée, et c'est vraiment très très rare.

    Sauf en 32 bits. Où il est facile de se retrouver dans ce cas après avoir alloué puis libéré de grosses quantitées de mémoire (~1 GB ). D'où l'intérêt d'utiliser un noyau 64 bits dans ce genre de cas.

    Oui, mais pas seulement.

    Ici, on est en userland, donc on parle de mémoire virtuelle. Sur 32-bit, cette espace est de 4GiB, dont 1GiB (*) est réservé pour l ́espace d ́adressage noyau (les pages de code (text) du noyau est mappé dans l ́espace virtuel de tous les processus, mais elles ne sont pas nécessairement exécutables : cela sert par exemple à appeler les syscals; les pages de data ne sont pas (toutes?) mappées dans l ́espace d ́adressage du noyau).

    Donc, il reste virtuellement (Haha!) 3GiB de disponible pour chaque processus en userland. Si ton processus essaye d ́allouer en séquence des blocs de (par exemple) 1MiB sans les libérer, alors arrivera un moment ou même l ́espace virtuel sera entièrement utilisé.

    Bien sûr, tu as aussi raison. Si tu alloues des blocs de 1MiB en séquence jusqu`à plus-soif, que tu en libères alternativement un sur deux, et qu ́ensuite tu tentes d ́allouer un bloc de 2MiB, alors tu as virtuellement de la place, mais pas contigüe, donc l ́allocation vas échouer.

    Donc, la règle générale deviendrai un truc du genre :

    sous Linux (et aussi la plupart des vrais OS), l ́allocation (malloc et consorts) n ́échoue jamais, sauf dans certains cas d ́exception (mémoire fragmentée, épuisement de l ́espace de mémoire virtuelle).

    (*) la découpe noyau/userland est par défaut 1GiB/3GiB, mais 2GiB/2GiB ou 3GiB/1GiB est aussi possible.

    Hop,
    Moi.