-3
votes

C - Pouvez-vous libérer des adresses de mémoire individuelles d'un tableau alloué de manière dynamique?

Je ne semble pas trouver une réponse à cette question. Pourquoi vous ne pouvez pas libérer d'une adresse individuelle, c'est parce que l'espace doit être continu? et s'il s'agit de la réponse, pourquoi la fragmentation se produit sur des disques durs


7 commentaires

l'espace doit être continu - bon


La fragmentation sur le disque dur se produit exactement car la HD permet de "libérer" l'espace entre les blocs, c'est-à-dire supprimer n'importe quel fichier.


Parce qu'il est mis en œuvre de cette façon. La mise en œuvre afin que chaque octet individuel puisse être libéré, ajoutera beaucoup de frais généraux pour la comptabilité.


Vous pouvez munmap une page de mémoire au milieu d'un grand segment mmap .


Vous pouvez implémenter vos propres remplacements pour MALLOC et gratuit avec cette fonctionnalité. Je soupçonne que quelque part pendant le processus de le faire, vous aurez compris pourquoi ce n'est pas une fonctionnalité communément prise en charge. Mais ce serait possible. =)


Si les adresses de la mémoire individuelles sont à la fin de la matrice, realloc peut faire cela.


Commentaire - Seul l'espace d'adressage virtuel est continu, la mémoire physique d'un tableau peut être un ensemble de pages de 4 kb dispersées et nécessite une cartographie de virtuelle à un processus ou un thread pour accéder à cette mémoire. Si vous effectuez des E / S DMA, l'espace d'adressage virtuel de la mémoire tampon doit être mappé dans un ensemble de compensations et de longueurs de mémoire physique, en fonction des pages de 4 Ko ou des parties de ces pages.


5 Réponses :


0
votes

première question non comme vous ne pouvez libérer que toute la mémoire allouée par une fonction familiale Malloc

La fragmentation des disques durs n'a rien d'autre avec les allocations de mémoire.


1 commentaires

La première question était "pourquoi?".



0
votes

L'allocation de mémoire est traitée comme des blocs de mémoire apparemment continue (cependant de la mémoire physique, mais ce n'est pas pertinent).

Il n'y a pas de moyen simple de "couper un trou" dans une seule allocation de mémoire, mais Vous pouvez faire quelque chose comme ceci: xxx

Certains systèmes de fichiers Linux permettent des "trous de poinçonnage" dans les fichiers, donc avec un fichier MMAP'ed, vous pourrez peut-être utiliser < Code> Fallocat SystemCall dessus tout en l'utilisant comme une matrice en mémoire.


0 commentaires

1
votes

Pouvez-vous libérer des adresses de mémoire individuelles d'un tableau attribué dynamiquement? SUB> P>

Si la mémoire est à la fin d'un tableau, vous pouvez libérer l'excès inutile en effectuant un realloc code> à une taille plus petite, avec la mise en garde que vous pourriez réellement obtenir un nouveau pointeur à nouveau. La mémoire avec le contenu du préfixe est copiée et la mémoire originale libérée dans son intégralité. P>

sinon, non. L'interface libres > est définie pour uniquement accepter les adresses renvoyées à partir de masloc code>, calloc code> ou realloc code>. P>

Pourquoi vous ne pouvez pas libérer d'adresses individuelles, c'est parce que l'espace doit être continu? SUB> P> BlockQuote>

Eh bien, la réponse directe est qu'il n'ya aucune interface définie pour le faire. Il n'y a aucun moyen de dire gratuit code> quelle quantité de pointeur que vous avez transmise devrait être libérée. Si vous souhaitez libérer toute la mémoire à la fin du bloc attribué, realloc code> est-ce. P>

Si la contigutilité n'est pas importante pour votre programme, utilisez simplement des allocations distinctes pour chaque élément de matrice. et libérez-les individuellement. P>

et s'il s'agit de la réponse, pourquoi la fragmentation se produit sur des disques durs sub> p> blockQquote>

Un moyen d'imaginer un scénario de fragmentation sur un système de fichiers est que si trois fichiers sont créés l'une après l'autre, puis le milieu est supprimé, il existe maintenant un trou entre deux fichiers. P >

|---File 1---|---File 4...|---File 3---|...File 4---|


0 commentaires

1
votes

largement, la raison pour laquelle vous ne pouvez pas libérer des parties individuelles de la mémoire allouée est qu'elle n'est pas suffisamment utile pour justifier écrire le logiciel pour le supporter.

La standard C spécifie des services fournis par Malloc , gratuit , realloc et routines associées. Les seules dispositions qu'il permettent de libérer de l'espace sont en utilisant libres pour libérer une allocation et en utilisant realloc pour remplacer une allocation avec un plus petit. Les implémentations

C sont libres d'étendre la norme C en fournissant des services pour libérer des portions d'espace alloué. Cependant, je ne suis au courant d'aucun qui l'a fait. Si un programme a été autorisé à libérer des pièces de mémoire arbitraires, le logiciel de gestion de la mémoire devrait garder une trace de toutes. Cela nécessite des données et du temps supplémentaires. De plus, il peut interférer avec certains schémas pour la gestion de la mémoire. Le logiciel de gestion de la mémoire peut organiser la mémoire de sorte que les attributions de tailles particulières puissent être satisfaites rapidement à partir de piscines spécialisées et devoir reprendre une partie de la taille arbitraire qui faisait partie d'un pool spécialisé pourrait être un problème.

S'il y avait une demande d'un tel service, il pourrait être écrit. Mais les programmes et les algorithmes ont évolué au fil des ans pour utiliser les services existants et il ne semble pas y avoir beaucoup de besoin de libérer des portions individuelles d'allocations. Généralement, si un programme va travailler avec de nombreux objets qu'il pourrait libérer individuellement, il les attribue individuellement. Ceci est courant lorsque vous construisez des structures de données de toutes sortes, en utilisant des pointeurs pour construire des arbres, des tableaux hachés de listes ou d'autres structures, etc. Les structures de données sont souvent construites à partir de nœuds individuels pouvant être attribués ou libérés individuellement. Donc, il y a peu de besoin de sculpter des morceaux individuels à libérer des allocations plus grandes.

L'organisation de la mémoire a très peu à voir avec l'organisation de données sur le disque dur ou d'autres supports de stockage. Les données sont généralement transférées entre les endroits arbitraires sur le disque et les endroits arbitraires de la mémoire selon les besoins. Dans une variété de circonstances, les fichiers sont "Mémoire mappés", ce qui signifie que le contenu d'un fichier est visible en mémoire de sorte que l'on puisse lire le contenu du fichier en lisant la mémoire et on peut modifier le fichier en modifiant la mémoire. Cependant, même dans cette situation, il n'y a généralement aucune relation entre l'endroit où les blocs du fichier sont sur le disque et où les blocs du fichier sont en mémoire. Les blocs d'un fichier sont gérés par le système de fichiers et ne sont pas nécessairement contigus, et les blocs de la mémoire sont gérés par le système de mémoire et peuvent être réarrangés de manière arbitraire avec prise en charge du matériel de mémoire virtuelle.


0 commentaires

0
votes

Pouvez-vous libérer des adresses de mémoire individuelles d'un tableau alloué de manière dynamique?

Vous semblez reconnaître que la réponse est "non", car vous suivez

Pourquoi vous ne pouvez pas libérer d'une adresse individuelle, c'est parce que l'espace doit être continu?

Chaque allocation individuelle est continue, mais l'union de tous les espaces alloués de manière dynamique n'est en aucun cas certain d'être continu. Plus sur cela plus tard.

Au niveau le plus pratique, vous ne pouvez pas libérer de morceaux d'une allocation plus importante car c ne fournit aucun mécanisme pour le faire. En particulier, parmi Les spécifications du gratuit () fonction est:

Si l'argument ne correspond pas à un pointeur précédemment renvoyé par une fonction de gestion de la mémoire, ou si l'espace a été traité par un appel à libérer ou à realloc, le comportement est indéfini.

Ainsi, gratuit () Exhibits UB si son argument est un pointeur à l'intérieur d'un bloc attribué.

Remarque également que gratuit () n'accepte qu'un seul paramètre. Il ne prévoit aucune disposition pour que l'appelant spécifie la quantité de mémoire libre, le sous-système de gestion de la mémoire doit donc comprendre que l'argument de l'argument présenté. C'est bon pour le modèle d'exploitation que l'on ne libère que des blocs entiers, déjà alloués, mais il ne supporte pas facilement libérer une allocation en plusieurs morceaux.

En outre, considérons que, bien que vous ne puissiez pas libérer des morceaux spécifiques d'une allocation plus grande, vous pouvez utiliser utiliser realloc () pour réduire la taille d'une allocation (qui peut aussi impliquer le déplacement).

n'importe quoi au-delà de cela est dans le domaine du comportement spécifique à la mise en œuvre, mais gardez à l'esprit que

  • Il est très courant que l'allocation soit effectuée et comptabilisée en termes de blocs multi-octets - par exemple, des multiples de 16 octets - quelles que soient les tailles spécifiques demandées. Une implémentation qui fonctionne de cette façon ne peut en aucun cas des blocs partiels libres, bien que l'on puisse imaginer pouvoir libérer des blocs individuels d'une allocation plus importante.

  • Certaines implémentations stockent des métadonnées de gestion de la mémoire adjacentes à l'espace alloué de manière dynamique présentée au programme. Dans une telle mise en œuvre, il n'est pas utile de libérer des morceaux d'une plus grande allocation car ils ne peuvent, en général, être réutilisés jusqu'à ce que toute l'allocation soit libérée, car il n'y a pas de lieu disponible pour les métadonnées nécessaires.

    et s'il s'agit de la réponse, alors pourquoi la fragmentation se produit sur des disques durs

    Vous n'avez pas besoin de libérer des allocations en morceaux pour obtenir une fragmentation de la mémoire. Il peut suffire d'effectuer plusieurs allocations et libérées ensuite uniquement certaines d'entre elles. Il s'agit d'un vrai problème qui peut dégrader les performances et même causer des programmes à échouer.

    avec cela dit, cependant, les systèmes de fichiers utilisent généralement des méthodes et des structures de données différentes pour suivre leurs métadonnées que les implémentations de gestion de la mémoire C, et le matériel sous-jacent a des caractéristiques et un comportement différents, il n'y a donc vraiment aucune justification pour former des attentes sur la comportement et capacités d'une variété de stockage basé sur le comportement et les capacités de l'autre.


0 commentaires