Discussion :

[Gruik]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

char pouet[500000];

?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

char pouet2[3630000];

?

Et pour l'allocation dynamique, est on seulement limités par la RAM (et le swap) ?
Peut on fair un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

malloc (9350000);

?

Merci

[Emmanuel Delahaye]

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())
  

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).

Peut on declarer des tableaux tres grands genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

char pouet[500000];

?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

char pouet2[3630000];

?

On peut, mais ce n'est pas garanti par le langage. Voir la doc du compilateur.

Et pour l'allocation dynamique, est on seulement limités par la RAM (et le swap) ?
Peut on fair un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

malloc (9350000);

?

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.

[Mac LAK]

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 ! ;-)

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.

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.

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).

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.

[Gruik]

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.

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).

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.

[Emmanuel Delahaye]

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

[Gruik]

Ah ca vrai, tu l'avais deja dit en plus...

[Mac LAK]

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... ;-)

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).

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

Merci à vous deux.

Pas de quoi. Tu mets un p'tit [Résolu] ? ;-)