Quelques questions sur la mémoire
Bonjour,
Je sais qu'il existe un "segment de données" déterminé à la compilation où sont rangés les variables globales (et variables locales statiques). Je sais que les variables locales sont empilés dans une zone mémoire (dont la taille est definie par le compilateur) appelée "pile".
Maintenant, quand on fait de l'allocation dynamique, les bouquins de C parlent du "tas", qu'est-ce donc, exactement?
Mes questions étaient : le segment de données est il limité? Peut on declarer des tableaux tres grands genre :
Code:
char pouet[500000];
?
Code:
char pouet2[3630000];
?
Et pour l'allocation dynamique, est on seulement limités par la RAM (et le swap) ?
Peut on fair un
?
Merci
Re: Quelques questions sur la mémoire
Citation:
Envoyé par Gruik
Je sais qu'il existe un "segment de données" déterminé à la compilation où sont rangés les variables globales (et variables locales statiques). Je sais que les variables locales sont empilés dans une zone mémoire (dont la taille est definie par le compilateur) appelée "pile".
Maintenant, quand on fait de l'allocation dynamique, les bouquins de C parlent du "tas", qu'est-ce donc, exactement?
Ces notions dépendent de l'implémentation. La définition du langage C se contente de parler de
- memoire statique (variables permanentes)
- memoire automatique (paramètre, variables locales)
- memoire allouée (malloc())
Citation:
Mes questions étaient : le segment de données est il limité?
Par l'implémentation, oui. La norme impose un minimum de 32767 (C90) ou 65535 (C99).
Citation:
Peut on declarer des tableaux tres grands genre :
Code:
char pouet[500000];
?
Code:
char pouet2[3630000];
?
On peut, mais ce n'est pas garanti par le langage. Voir la doc du compilateur.
Citation:
Et pour l'allocation dynamique, est on seulement limités par la RAM (et le swap) ?
Peut on fair un
?
Dans tous les cas :
- Un tableau statique ne peut excéder ((size_t)-1) bytes
- Un tableau alloué par malloc() ne peut excéder ((size_t)-1) bytes
- Un tableau alloué par calloc() ne peut excéder ((size_t)-1) * ((size_t)-1) bytes
Mais en réalité, c'est probablement moins. En cas d'echec de *alloc(), une valeur 0 (NULL) est retournée.
Re: Quelques questions sur la mémoire
Citation:
Envoyé par Gruik
Maintenant, quand on fait de l'allocation dynamique, les bouquins de C parlent du "tas", qu'est-ce donc, exactement?
Sous DOS, tu as donc la pile (stack), le(s) segment(s) de code (CS, Code Segment) et LE segment de données (DS, Data Segment). C'est pas réellement spécifique au C, d'ailleurs : la preuve est que le nom des registres de segment du 80x86 sont justement CS, DS et SS (Stack Segment) pour ces éléments. Voilà pour les termes "segment de ???".
Le tas (heap), c'est la mémoire restante et qui n'est pas déjà utilisée par l'OS. C'est pas un terme nouveau, cependant.
Sur un OS multitâche, tu peux avoir deux sortes de tas, suivant les implémentations : un tas "local", associé exclusivement au processus courant, et un tas "global", géré par l'OS. Souvent, le tas "local" est en fait simulé par (ré)allocation d'un buffer sur le tas global, buffer partagé ensuite par les allocations unitaires de ton programme.
Ceci permet, sans garbage collector, de libérer toute la mémoire allouée en fin de programme, simplement en libérant le buffer du tas local.
De toutes façons, le tas local est géré par la CLib ou l'API, c'est transparent. Et ça ne dispense pas de libérer proprement sa mémoire ! ;-)
Citation:
Envoyé par Gruik
Mes questions étaient : le segment de données est il limité?
Oui, toujours. 64 ko sur DOS en modèle large, par exemple. Dépend du processeur, du modèle mémoire (si ça a un sens), de l'OS, et du compilateur. Bref, de tout ! ;-)
Sous Windows, on outrepasse cette limite en utilisant les ressources d'exécutable, notamment, qui permettent de linker de nombreuses (et volumineuses) données à l'exécutable tout en n'encombrant pas le segment de données.
Citation:
Envoyé par Gruik
Peut on declarer des tableaux tres grands genre...
Franchement déconseillé : si le segment de données "déborde", t'es mort, il est même très probable que ton programme refuse carrément de se linker.
Citation:
Envoyé par Gruik
Et pour l'allocation dynamique, est on seulement limités par la RAM (et le swap) ?
Oui, en faisant attention à ce que tu appelles "RAM"... C'est la RAM disponible, c'est à dire celle qui n'est pas utilisée par ton code, tes données statiques, ta pile, les autres processus et l'OS.
La taille maximale de l'allocation dépend de la fragmentation du tas : ce n'est pas parceque tu as 200 Mo de RAM libre que tu peux allouer un tableau de 200 Mo, justement : il n'est pas dit que ces 200 Mo soient contigüs !!
Pour cette raison, j'ai tendance à allouer les tableaux multidimensionnels via une série d'allocations de "lignes" unitaires (reposte si tu ne vois pas de quoi je veux parler).
Théoriquement, tu ne peux/dois pas toucher au swap, c'est l'OS qui s'en charge. Tu as des flags lors des allocations qui indiquent si le bloc peut (ou pas) être swappé par l'OS, mais là, faut aller dans le forum de ton OS cible. En général, on n'accède pas à de la mémoire swappable par un pointeur, mais par un handle, en demandant à l'OS la mise à disposition du bloc lorsque le besoin s'en fait sentir (et en lui indiquant qu'on a fini de s'en servir lorsque c'est le cas, afin de pouvoir swapper de nouveau les données).
Citation:
Envoyé par Gruik
Peut on fair un malloc (9350000) ?
Si le triplet OS/compilo/CLib permet de passer une telle valeur, et si tu as un bloc libre sur le tas d'un peu plus de 9 Mo contigüs, oui.
L'OS peut, parfois, prendre beaucoup de temps ("beaucoup" pour un CPU, j'entends) pour allouer la mémoire, car pour allouer ce que tu as demandé, il peut être amené à swapper plusieurs blocs pour obtenir une zone de la taille requise (et contigüe !).
C'est transparent, mais il est crucial de respecter à la lettre les séquences d'appel à l'API de l'OS et de tester tous les codes de retour à chaque étape.
Re: Quelques questions sur la mémoire
Citation:
Envoyé par Mac LAK
Le tas (heap), c'est la mémoire restante et qui n'est pas déjà utilisée par l'OS. C'est pas un terme nouveau, cependant.
Sur un OS multitâche, tu peux avoir deux sortes de tas, suivant les implémentations : un tas "local", associé exclusivement au processus courant, et un tas "global", géré par l'OS. Souvent, le tas "local" est en fait simulé par (ré)allocation d'un buffer sur le tas global, buffer partagé ensuite par les allocations unitaires de ton programme.
Ceci permet, sans garbage collector, de libérer toute la mémoire allouée en fin de programme, simplement en libérant le buffer du tas local.
De toutes façons, le tas local est géré par la CLib ou l'API, c'est transparent. Et ça ne dispense pas de libérer proprement sa mémoire ! ;-)
Ah oué... en gros, le tas est une zone mémoire allouée pour l'allocation dynamique du programme et un tas plus gros et alloué quand y plus de place dedans.
Citation:
Envoyé par Mac LAK
Oui, en faisant attention à ce que tu appelles "RAM"... C'est la RAM disponible, c'est à dire celle qui n'est pas utilisée par ton code, tes données statiques, ta pile, les autres processus et l'OS.
La taille maximale de l'allocation dépend de la fragmentation du tas : ce n'est pas parceque tu as 200 Mo de RAM libre que tu peux allouer un tableau de 200 Mo, justement : il n'est pas dit que ces 200 Mo soient contigüs !!
Pour cette raison, j'ai tendance à allouer les tableaux multidimensionnels via une série d'allocations de "lignes" unitaires (reposte si tu ne vois pas de quoi je veux parler).
Théoriquement, tu ne peux/dois pas toucher au swap, c'est l'OS qui s'en charge. Tu as des flags lors des allocations qui indiquent si le bloc peut (ou pas) être swappé par l'OS, mais là, faut aller dans le forum de ton OS cible. En général, on n'accède pas à de la mémoire swappable par un pointeur, mais par un handle, en demandant à l'OS la mise à disposition du bloc lorsque le besoin s'en fait sentir (et en lui indiquant qu'on a fini de s'en servir lorsque c'est le cas, afin de pouvoir swapper de nouveau les données).
Oui oui, j'appelais RAM, l'ensemble de la mémoire vive (je voulais dire que le swap faisait parti de la mémoire vive).
Citation:
Envoyé par Mac LAK
Si le triplet OS/compilo/CLib permet de passer une telle valeur, et si tu as un bloc libre sur le tas d'un peu plus de 9 Mo contigüs, oui.
L'OS peut, parfois, prendre beaucoup de temps ("beaucoup" pour un CPU, j'entends) pour allouer la mémoire, car pour allouer ce que tu as demandé, il peut être amené à swapper plusieurs blocs pour obtenir une zone de la taille requise (et contigüe !).
C'est transparent, mais il est crucial de respecter à la lettre les séquences d'appel à l'API de l'OS et de tester tous les codes de retour à chaque étape.
Ouais je teste rarement le retour de malloc.. j'ai tort.
Ca m'embete d'alourdir le code pour un cas qui a tres peu de chances d'arriver.
Bah au pire ca provequera une segmentation fault si ya plus de mémoire.
Merci à vous deux.
Re: Quelques questions sur la mémoire
Citation:
Envoyé par Gruik
Ouais je teste rarement le retour de malloc.. j'ai tort.
Ca m'embete d'alourdir le code pour un cas qui a tres peu de chances d'arriver.
Bah au pire ca provoquera une segmentation fault si ya plus de mémoire.
Non. Le déréférencement d'un pointeur NULL provoquera un comportement indéfini qui se traduira par n'importe quoi. Le 'segfault' est une réaction parmi d'autres. Une réaction dangereuse serait un comportement qui ressemble à un comportement attendu (déjà vu sous DOS en modèle de mémoire small). Pour éviter ça, il est indispensable de tester tous les retours de *alloc().
http://emmanuel-delahaye.developpez.com/init_c.htm#UB
http://emmanuel-delahaye.developpez....tes.htm#malloc
Re: Quelques questions sur la mémoire
Citation:
Envoyé par Gruik
Ah oué... en gros, le tas est une zone mémoire allouée pour l'allocation dynamique du programme et un tas plus gros et alloué quand y plus de place dedans.
En gros, oui. Le point important (et problématique), c'est que cette zone est plus ou moins partagée par tous les processus sur un OS multitâche, il faut donc faire attention à ne pas allouer 50 Mo si tu n'as besoin que de 2 Mo, faut être partageur... ;-)
Citation:
Envoyé par Gruik
Oui oui, j'appelais RAM, l'ensemble de la mémoire vive (je voulais dire que le swap faisait parti de la mémoire vive).
Justement, non, le swap n'est pas de la RAM disponible... C'est une "réserve de secours" pour l'OS, ou un "tiroir de rangement temporaire" suivant le cas. Tu ne peux pas allouer sur le swap, seul l'OS en est capable. Par contre, tu peux utiliser et créer tes propres fichiers de swap, mais tu devras les gérer toi-même (c'est souvent le souk, d'ailleurs).
Citation:
Envoyé par Gruik
Ouais je teste rarement le retour de malloc.. j'ai tort.
Ca m'embete d'alourdir le code pour un cas qui a tres peu de chances d'arriver.
Bah au pire ca provequera une segmentation fault si ya plus de mémoire.
Pour un malloc raisonnable (allocation <10% de la mémoire totale du PC), c'est rarement refusé, c'est vrai.
Ce que je fais, c'est que pour mes tests "rapides", je teste rarement le retour des mallocs. Par contre, une fois le principe fonctionnel (comportement nominal OK), je rajoute alors les tests sur les retours.
Par contre, pour les "grosses" allocations, je teste toujours et systématiquement, même lors des essais : là, par contre, ça arrive (assez) souvent que ce soit refusé, surtout si tu as une fuite mémoire.
Mais pour les allocations sur l'OS, c'est pas une GPF que tu vas avoir, c'est plutôt un crash direct de l'appli (voire de l'OS !) qui va arriver, et là, c'est beaucoup plus grave. C'est plutôt "Au mieux, ça provoquera...". Le pire, t'imagines même pas... :-D
Citation:
Envoyé par Gruik
Merci à vous deux.
Pas de quoi. Tu mets un p'tit [Résolu] ? ;-)
