Réservation espace mémoire par windows

Papouille wrote on 06/02/2008 23:01:

dans un programme C, il y a [...]
- le segment stack
- le heap (malloc...)

Lorsque le programme est chargé en mémoire, comment windows fait-il pour
savoir quelle est la quantité de mémoire à réserver à la pile (stack) et
au heap ?

la question est propre au format PE des exec. microsoft pas au C.
l'OS le sait car ces infos sont des params transmis au linkeur et donc
présentes dans l'exec.

Sylvain.

Sylvain wrote:

Papouille wrote on 06/02/2008 23:01:

dans un programme C, il y a [...]
- le segment stack
- le heap (malloc...)

Lorsque le programme est chargé en mémoire, comment windows fait-il
pour savoir quelle est la quantité de mémoire à réserver à la pile
(stack) et au heap ?

la question est propre au format PE des exec. microsoft pas au C.
l'OS le sait car ces infos sont des params transmis au linkeur et donc
présentes dans l'exec.

Sylvain.

La reponse, c'est qu'il n'en sait rien. Et qu'il n'a de toute facon
aucun moyen de le savoir, a moins bien sur que le programmeur le
specifie quelque part ce qui a ma connaissance n'arrive pas.
Sauf erreur de ma part, le tas (heap) est alloue sur demande dans une
zone partage par tous les processes windows. Partant de la, l'OS croise
les doigts pour qu'il n'y ait pas de debordement.

Papouille <Papouille@papouille.net> écrivait :

Bonjour,

dans un programme C, il y a 4 zones d'espace mémoire :
- le segment de code
- le segment de données (variables extern et static)
- le segment stack
- le heap (malloc...)

moi j'ai des programmes C avec nettement plus de sections que ça
(données initialisées, données non initialisées, image d'initialisation
des données, constantes, etc..., et plusieurs de chques à chaque fois).

Ça dépend de la plateforme, pas du langage.

Lorsque le programme est chargé en mémoire, comment windows fait-il
pour savoir quelle est la quantité de mémoire à réserver à la pile
(stack) et au heap ?

Ça c'est la tambouille de windows, du compilateur, du linker
(dynamique), etc. Mais surtout pas du C qui ne fait que demander de la
mémoire au système.

--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé

Sylvain wrote:

Papouille wrote on 06/02/2008 23:01:

dans un programme C, il y a [...]
- le segment stack
- le heap (malloc...)

Lorsque le programme est chargé en mémoire, comment windows fait-il
pour savoir quelle est la quantité de mémoire à réserver à la pile
(stack) et au heap ?

la question est propre au format PE des exec. microsoft pas au C.
l'OS le sait car ces infos sont des params transmis au linkeur et donc
présentes dans l'exec.

Sylvain.

La reponse, c'est qu'il n'en sait rien. Et qu'il n'a de toute facon
aucun moyen de le savoir, a moins bien sur que le programmeur le
specifie quelque part ce qui a ma connaissance n'arrive pas.
Sauf erreur de ma part, le tas (heap) est alloue sur demande dans une
zone partage par tous les processes windows. Partant de la, l'OS croise
les doigts pour qu'il n'y ait pas de debordement.
absolument pas, c'était comme ça sous dos mais pas sous un systeme

évolué. Lorsqu'un programme fait un malloc(), le malloc regarde le heap
(mémoire allouée dynamiquement) pour voir si il sait caser le morceau
demandé. Autrement, il demande une ou plusieurs pages qui sont placées à
la fin du heap. La pagination permet d'empecher justement qu'un
programme déborde de la page et ecrive dans la memoire d'un autre
processus. Mais l'important est qu'on obtient un espace d'adressage
virtuel contigü.

Pour le stack c'est totalement transparent : lorsqu'il y a une faute de
page (page non présente) sur le stack ET que le registre pointeur de
stack est cohérent (pointe dans cette page, et la page pas trop éloignée
de la precedente, etc.) alors l'OS alloue une nouvelle page pour
agrandir le stack. Ce qui fait que sur une machine moderne avec un stack
moderne on peut puiser très très loin dans le stack avant d'avoir un crash.

Et comme ont dit d'autres personnes, c'est une question spécifique à
l'os (meme si ils fonctionnent quasiment tous de la même manière
aujourd'hui, à part peut-être IOS) et non au langage.

En news:86tzkljkuf.fsf@nez-casse.depot.rail.eu.org, Erwan David va escriure:

Papouille <Papouille@papouille.net> écrivait :

dans un programme C, il y a 4 zones d'espace mémoire :
- le segment de code

« Fonctions »

- le segment de données (variables extern et static)

« Objets à durée de stockage statique »

- le segment stack

« Objets à durée de stockage automatique »

- le heap (malloc...)

« Objets à durée de stockage allouée »

moi j'ai des programmes C avec nettement plus de sections que ça

Mais il s'agit d'une extension.

Ça dépend de la plateforme, pas du langage.

Eh non, il a raison sur le fond même si les termes sont différents dans la
norme (6.2.4, 6.9).

Lorsque le programme est chargé en mémoire, comment windows fait-il
pour savoir quelle est la quantité de mémoire à réserver à la pile
(stack) et au heap ?

Ça c'est la tambouille de windows, du compilateur, du linker
(dynamique), etc.

Yep.

Mais surtout pas du C qui ne fait que demander de la
mémoire au système.

Même pas. « Le C » ne demande rien. La seule « demande », c'est celle
provenant de l'allocation dynamique (malloc), qui dépend évidemment de la
plateforme. Quant à l'architecture pour la pile (durée automatique), c'est
fixée en général par l'architecture.


Antoine

En news:47aa2e33$0$8310$426a74cc@news.free.fr, Papouille va escriure:

dans un programme C, il y a 4 zones d'espace mémoire :
- le segment de code
- le segment de données (variables extern et static)
- le segment stack
- le heap (malloc...)

Lorsque le programme est chargé en mémoire, comment windows fait-il
pour savoir quelle est la quantité de mémoire à réserver à la pile
(stack) et au heap ?

L'architecture Win32 dit (disait?) que pour la pile, par défaut c'est 1 Mo
(± 8 Ko, je ne sais plus les détails de tête). Si tu fais une allocation
brutale d'un objet automatique plus grand, cela coince.
Certains environnements C (dont celui de Microsoft, si je me souviens bien)
sont spécialement reprogrammés pour s'affranchir de cette limite (si tu
déclares un grand tableau auto, le compilo génère des appels en plus au
système pour éviter le problème). D'autres savent récupérer l'exception et
requalifier la mémoire en « utilisable ». Il y a aussi des options à
l'édition de liens (-stack) qui permette de changer la valeur par défaut.
Bref si tu as des problèmes pratiques, il y a des solutions ad hoc (qui te
seront détaillées le cas échéant sur le groupe adéquat, pas ici merci.)

Il n'y a pas de mémoire réservée pour le tas (j'ai du mal à comprendre la
question, en fait).

Tu as par ailleurs une limite à 2 Go, ampliable globalement à 3Go, pour
l'espace d'adressage, qui est partagé (adressage linéaire).
Et aussi éventuellement des quotas.

Tout ceci est de la mémoire virtuelle, pas grand chose à voir (du moins
directement) avec la mémoire physique (celle qui est écrite sur ton bon de
commande).


Pour Win64, je n'en sais rien (sauf qu'évidemment, il n'y a en pratique pas
de limite de l'espace d'adressage).


Antoine

Aris wrote:

Sylvain wrote:

Papouille wrote on 06/02/2008 23:01:

dans un programme C, il y a [...]
- le segment stack
- le heap (malloc...)

Lorsque le programme est chargé en mémoire, comment windows fait-il
pour savoir quelle est la quantité de mémoire à réserver à la pile
(stack) et au heap ?

la question est propre au format PE des exec. microsoft pas au C.
l'OS le sait car ces infos sont des params transmis au linkeur et
donc présentes dans l'exec.

Sylvain.

La reponse, c'est qu'il n'en sait rien. Et qu'il n'a de toute facon
aucun moyen de le savoir, a moins bien sur que le programmeur le
specifie quelque part ce qui a ma connaissance n'arrive pas.
Sauf erreur de ma part, le tas (heap) est alloue sur demande dans une
zone partage par tous les processes windows. Partant de la, l'OS
croise les doigts pour qu'il n'y ait pas de debordement.
absolument pas, c'était comme ça sous dos mais pas sous un systeme

évolué. Lorsqu'un programme fait un malloc(), le malloc regarde le heap
(mémoire allouée dynamiquement) pour voir si il sait caser le morceau
demandé. Autrement, il demande une ou plusieurs pages qui sont placées à
la fin du heap. La pagination permet d'empecher justement qu'un
programme déborde de la page et ecrive dans la memoire d'un autre
processus. Mais l'important est qu'on obtient un espace d'adressage
virtuel contigü.

Heu... il me semble que la question portait plutot sur la reservation au
chargement -- donc avant l'execution du programme (et des malloc) --
d'une zone dans le tas (heap) pour le process.
Et je maintiens ca n'existe pas sous windows (pas plus que sous dos).
Autrement dis, il n'y a pas de quota.

Merci à tous.

Je comprends que c'est le linker qui au départ construit un exécutable
au formet PE en réservant de la place pour le heap dans l'espace des
adresses mémoires virtuelles.

Charge ensuite à Windows d'utiliser le paging pour allouer plus ou moins
de mémoire au process au fur et à mesure de l'utilisation de malloc(),
et de swapper sur le disque dur en cas de dépassement de capacité de
mémoire physique.

L'architecture Win32 dit (disait?) que pour la pile, par défaut c'est 1 Mo
(± 8 Ko, je ne sais plus les détails de tête). Si tu fais une allocation
brutale d'un objet automatique plus grand, cela coince.
Certains environnements C (dont celui de Microsoft, si je me souviens bien)
sont spécialement reprogrammés pour s'affranchir de cette limite (si tu
déclares un grand tableau auto, le compilo génère des appels en plus au
système pour éviter le problème). D'autres savent récupérer l'exception et
requalifier la mémoire en « utilisable ». Il y a aussi des options à
l'édition de liens (-stack) qui permette de changer la valeur par défaut.
Bref si tu as des problèmes pratiques, il y a des solutions ad hoc (qui te
seront détaillées le cas échéant sur le groupe adéquat, pas ici merci.)

OK. Merci.

Il n'y a pas de mémoire réservée pour le tas (j'ai du mal à comprendre la
question, en fait).

Je pense à un process avec son segment de code, de données et sa pile,
avec de la place en plus allouée entre la pile et les données de telle
sorte que la pile peut augmenter ainsi que le nombre de données sans
pour autant forcer le process à se mettre en "attente", swapper sur le
disque dur en attendant que de la place se libère, ou soit tué.

A priori, cette réservation de place se fait en mémoire virtuelle. La
mémoire physique correspondante est donc gérée par le hardware en
général, et la MMU du microprocesseur en particulier, ce qui permet de
s'affranchir des contraintes physiques (taille mémoire limitée).

Tu as par ailleurs une limite à 2 Go, ampliable globalement à 3Go, pour
l'espace d'adressage, qui est partagé (adressage linéaire).
Et aussi éventuellement des quotas.

L'espace d'adresses virtuelles est sur 32bits, ce qui fait 4Go, non ? Et
cet espace est propre à chaque process qui en dispose à volonté (charge
au hardware de mettre en oeuvre la pagination pour faire tenir cela en
mémoire physique). Donc pas de partage avec d'autres process au niveau
de la mémoire virtuelle.... non ?

Tout ceci est de la mémoire virtuelle, pas grand chose à voir (du moins
directement) avec la mémoire physique (celle qui est écrite sur ton bon de
commande).

Oui... en effet...

Pour Win64, je n'en sais rien (sauf qu'évidemment, il n'y a en pratique pas
de limite de l'espace d'adressage).

64 bits d'espace d'adresse ou 64 bits sur le bus de données ?

En news:47af4a08$0$24026$426a74cc@news.free.fr, Papouille va escriure:

Il n'y a pas de mémoire réservée pour le tas (j'ai du mal à
comprendre la question, en fait).

Je pense à un process avec son segment de code, de données et sa pile,
avec de la place en plus allouée entre la pile et les données de telle
sorte que la pile peut augmenter ainsi que le nombre de données sans
pour autant forcer le process à se mettre en "attente", swapper sur le
disque dur en attendant que de la place se libère, ou soit tué.

A priori, cette réservation de place se fait en mémoire virtuelle.

Euh oui, mais si tu atteins la limite de Win32 (qui dépend de nombreux
critères, dont la charge de la machine au moment où tu crées le processus),
il y a probablement un souci dans ton programme.

Tu as par ailleurs une limite à 2 Go, ampliable globalement à 3Go,
pour l'espace d'adressage, qui est partagé (adressage linéaire).
Et aussi éventuellement des quotas.

L'espace d'adresses virtuelles est sur 32bits, ce qui fait 4Go, non ?

Non. Dans le modèle Win32, les processus utilisateurs n'ont jamais accès aux
adresses supérieures à 0xC000_0000.

Et cet espace est propre à chaque process qui en dispose à volonté

Non, mais entrer dans les détails n'est pas le sujet de ce groupe.

Pour Win64, je n'en sais rien (sauf qu'évidemment, il n'y a en
pratique pas de limite de l'espace d'adressage).

64 bits d'espace d'adresse ou 64 bits sur le bus de données ?

Le premier. Le second n'a rien à voir avec le sujet, on s'en moque. Ainsi
les machines modernes x86-32 ont souvent des bus de données sur 36 bits
(actifs), mais cela est sans effet sur les processus.


Antoine