Sauf qu'en fait non, malloc appelle brk pour les allocs mémoire de moins d'une page, mais il appellera mmap si ça dépasse la taille d'une page. Donc tout dépend du type d'allocation mémoire dont on cause.
J'ai l'impression que sous linux on est foutu, on ne sait tout simplement rien faire du tout pour récupérer une situation de pénurie.
Oui et non. Il existe des softs qui se proposent de « surcharger » les allocations mémoire (par exemple un ancien collègue qui écrivait une bibliothèque de threads pour du calcul haute performance). Mon collègue utilisait les fonctions de « surcharge » de malloc pour rajouter des comportements spécifiques au moment de l'allocation mémoire. Dans ce cas on tombe sur des trucs rigolos, du genre tout un tas de logiciels GNU qui allouent presque tout l'espace mémoire adressable dans le processus car ils tablent sur l'allocation optimiste de Linux (en l'occurrence, c'est arrivé avec sort(1)). Du coup dans l'allocateur « normal » de Linux, sort te trie correctement les chaînes de caractères sans segfault car seules les pages réellement utilisées sont allouées par le système. Mais avec l'allocateur de mon collègue, tout à coup on avait des abort() et segfaults parce qu'il s'assurait que la mémoire était réellement allouée en initialisant au moins un octet pour chaque page théoriquement allouée1.
Tout un tas de softs avec des objectifs de performance proposent leurs propres ajouts (si ce n'est leur propre allocateur) aux mécanismes de gestion de mémoire de l'OS (SGBD, environnement d'exécution multithreadés, etc.).
en partie pour garantir autant d'allocation de pages mémoires physiquement contiguës que possible. ↩
[^] # Re: undefined behaviour
Posté par lasher . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 3.
Sauf qu'en fait non,
mallocappellebrkpour les allocs mémoire de moins d'une page, mais il appellerammapsi ça dépasse la taille d'une page. Donc tout dépend du type d'allocation mémoire dont on cause.Oui et non. Il existe des softs qui se proposent de « surcharger » les allocations mémoire (par exemple un ancien collègue qui écrivait une bibliothèque de threads pour du calcul haute performance). Mon collègue utilisait les fonctions de « surcharge » de malloc pour rajouter des comportements spécifiques au moment de l'allocation mémoire. Dans ce cas on tombe sur des trucs rigolos, du genre tout un tas de logiciels GNU qui allouent presque tout l'espace mémoire adressable dans le processus car ils tablent sur l'allocation optimiste de Linux (en l'occurrence, c'est arrivé avec
sort(1)). Du coup dans l'allocateur « normal » de Linux,sortte trie correctement les chaînes de caractères sans segfault car seules les pages réellement utilisées sont allouées par le système. Mais avec l'allocateur de mon collègue, tout à coup on avait desabort()et segfaults parce qu'il s'assurait que la mémoire était réellement allouée en initialisant au moins un octet pour chaque page théoriquement allouée1 .Tout un tas de softs avec des objectifs de performance proposent leurs propres ajouts (si ce n'est leur propre allocateur) aux mécanismes de gestion de mémoire de l'OS (SGBD, environnement d'exécution multithreadés, etc.).
en partie pour garantir autant d'allocation de pages mémoires physiquement contiguës que possible. ↩