Pre-scriptum: en lisant en diagonale certains liens que je cite, il est clair que mes souvenirs sont flous et blindés d'erreurs, mais pas le temps de tout lire (p'tet ce soir, ça me fera pas de mal), je prend juste une petite pause au taf... mea culpa.
J'attendais de voir un peu les réponses, en espérant que quelqu'un aborde la notion de page... pas de bol. Pour le coup, je risque de dire des choses assez fausses... N'hésites pas a vérifier ce que je raconte, ou mieux, a me corriger...
Or à un moment le tas va arriver vers la mémoire de la pile
Oui, ce genre de choses peut arriver. Enfin, pouvais arriver. Si je ne dis pas d'âneries (cf plus haut), les noyaux gèrent de nos jours la mémoire par pages. Ce que tu vois quand tu regardes les adresses mémoire de ton processus, ce sont de fausses adresses, au moins pour le tas.
Quand tu fais un appel a malloc (ou calloc, ou realloc, peu importe...), celui-ci va demander une page au noyau, qui la lui accordera (ou pas: renvoi de NULL/nullptr). Ensuite, il te fileras de petits morceaux de cette page, à la demande. Ce sont ces morceaux de pages qui, ensemble, vont constituer ton tas.
Le programmeur voit la mémoire comme linéaire grâce au noyau, et, je crois, de la MMU.
C'est ici l'intérêt d'avoir agrandit la taille des espaces d'adressage: en 16 bits, la mémoire virtuelle n'aurait jamais pu dépasser les 64Kio par processus. En 32 bits, les 4Gio par processus, et en 64 bits... euh... 264 -1 octets :)
Notes bien le "par processus", parce qu'il existe un mythe selon lequel les machine avec archi 32 bits ne peuvent pas gérer plus de 4Gio de RAM. C'est faux(bon, ok, dans certains cas, certes).
[^] # Re: derniere chose
Posté par freem . En réponse au message question sur la structure du code que fait le compilateur (.text, .bss, .heap ...). Évalué à 3.
Pre-scriptum: en lisant en diagonale certains liens que je cite, il est clair que mes souvenirs sont flous et blindés d'erreurs, mais pas le temps de tout lire (p'tet ce soir, ça me fera pas de mal), je prend juste une petite pause au taf... mea culpa.
J'attendais de voir un peu les réponses, en espérant que quelqu'un aborde la notion de page... pas de bol. Pour le coup, je risque de dire des choses assez fausses... N'hésites pas a vérifier ce que je raconte, ou mieux, a me corriger...
Oui, ce genre de choses peut arriver. Enfin, pouvais arriver. Si je ne dis pas d'âneries (cf plus haut), les noyaux gèrent de nos jours la mémoire par pages. Ce que tu vois quand tu regardes les adresses mémoire de ton processus, ce sont de fausses adresses, au moins pour le tas.
Quand tu fais un appel a malloc (ou calloc, ou realloc, peu importe...), celui-ci va demander une page au noyau, qui la lui accordera (ou pas: renvoi de NULL/nullptr). Ensuite, il te fileras de petits morceaux de cette page, à la demande. Ce sont ces morceaux de pages qui, ensemble, vont constituer ton tas.
Le programmeur voit la mémoire comme linéaire grâce au noyau, et, je crois, de la MMU.
C'est ici l'intérêt d'avoir agrandit la taille des espaces d'adressage: en 16 bits, la mémoire virtuelle n'aurait jamais pu dépasser les 64Kio par processus. En 32 bits, les 4Gio par processus, et en 64 bits... euh... 264 -1 octets :)
Notes bien le "par processus", parce qu'il existe un mythe selon lequel les machine avec archi 32 bits ne peuvent pas gérer plus de 4Gio de RAM. C'est faux(bon, ok, dans certains cas, certes).