Malloc et la fragmentation mémoire.
Etienne
Je voudrais juste être bien sûr !!!
lorsqu'on utilise des malloc et des free en C, il n'y a uncun mécanisme
possible de compactage de la mémoire.
Sans quoi je suppose que les adresses retournées par malloc ne seraient
plus valides !
Si par hasard j'étais dans l'erreur, comment pourrai fonctionner de tels
gestionnaire de mémoire ?
Merci
Etienne
JKB
Etienne <eti...@tlk.fr> écrivait :
> Bonjour.
Bonjour,
À ma connaissance, ça n'existe pas. Un tel outil ne pourrait pas
simplement aller modifier tous les pointeurs valides sauf à
introduire des algorithmes complexes (et encore...). C'est pour cela
qu'il existe des algorithmes best fit, first fit et quelques
autres... Voir poru cela sous Solaris :
libmtmalloc, libbsdmalloc, libmalloc, libumem...
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
Etienne
> À ma connaissance, ça n'existe pas. Un tel outil ne pourrait pas
> simplement aller modifier tous les pointeurs valides sauf à
> introduire des algorithmes complexes (et encore...).
Ok c'est bien ce que je pensais.
Donc les langages du type Java et autre qui utilisent un garbage
collector cache le pointeur dans la structure de l'objet afin de pouvoir
le modifier sans que cela n'ai d'incidence. le référence retourné c'est
finalement qu'un ID d'objet.
Comment fonctionne le C++ du coup ?
dispose t-il d'un garbage collector ?
Etienne
Fabien LE LEZ
>Comment fonctionne le C++ du coup ?
Grosso modo, comme C.
C++ permet juste d'automatiser des trucs que tu fais manuellement en
C.
>dispose t-il d'un garbage collector ?
Non. En théorie, on peut en rajouter un, mais je ne sais pas si c'est
utilisé : http://www.hpl.hp.com/personal/Hans_Boehm/gc/
Etienne
> On Mon, 02 May 2011 11:30:42 +0200, Etienne<eti...@tlk.fr>:
>
>> Comment fonctionne le C++ du coup ?
>
> Grosso modo, comme C.
> C++ permet juste d'automatiser des trucs que tu fais manuellement en
> C.
Ok merci.
Jo Engo
> À ma connaissance, ça n'existe pas. Un tel outil ne pourrait
> pas simplement aller modifier tous les pointeurs valides sauf à
> introduire des algorithmes complexes (et encore...).
(l'allocation réelle de la mémoire) et des pointeurs. Quelle
complication ? Une indirection de plus.
Bon ça demande d'ajuster le pattern des appels à malloc et à free mais il n'y a ruien de si compliqué que ça, si ?
exemples 4 zones de mémoires, 1, 2, 3, 4. 2 thread a b
tableau initial de correpondance
1 - 1 o
2 - 2 o
3 - 3 o
4 - 4 o
a demande une zone, reçoit 1
b demande une zone reçoit 2
1 - 1 x
2 - 2 x
3 - 3 o
4 - 4 o
a libère 1
le ramasse-miettes transfère le contenu de 2 vers 1 et le compacte
Tableau de correspondance
1 - p o @(1)<p≤@(2)
2 - 1 x
3 - 3 o
4 - 4 o
b a toujours la même adresse pour la zone de mémoire allouée bien que
l'@ physique n'est pas la même.
--
Tous les paranoïaques me persécutent (Umberto Eco)
JKB
Jo Engo <y...@bidart.net> écrivait :
>
>> À ma connaissance, ça n'existe pas. Un tel outil ne pourrait
>> pas simplement aller modifier tous les pointeurs valides sauf à
>> introduire des algorithmes complexes (et encore...).
>
> Hein ? Une simple table de correspondance entre des références chaînées
> (l'allocation réelle de la mémoire) et des pointeurs. Quelle
> complication ? Une indirection de plus.
>
> Bon ça demande d'ajuster le pattern des appels à malloc et à free mais il n'y a ruien de si compliqué que ça, si ?
>
> exemples 4 zones de mémoires, 1, 2, 3, 4. 2 thread a b
>
> tableau initial de correpondance
> 1 - 1 o
> 2 - 2 o
> 3 - 3 o
> 4 - 4 o
>
> a demande une zone, reçoit 1
> b demande une zone reçoit 2
> 1 - 1 x
> 2 - 2 x
> 3 - 3 o
> 4 - 4 o
>
> a libère 1
> le ramasse-miettes transfère le contenu de 2 vers 1 et le compacte
ton code est lui-aussi synchrone. Dès qu'un gestionnaire de signal
est appelé, ça commence à merdoyer, et je ne parle pas du code
multithreadé. Le problème est que pour faire ton truc, tu es
_obligé_ de jouer avec des mutexes ou/et des sémaphores pour ne pas
appeler d'un thread un pointeur qui est modifié par ton ramasse-
miette dans ton dos d'un autre thread. Et comme la libpthread n'est
pas 'async signal safe', le résultat n'est pas trivial du tout. Ça
fait quelques années que je regarde ça (et que d'autres que moi
regardent ça de près) et je n'ai pas encore vu un truc sérieux
sortir. Par sérieux, j'entends quelque chose qui est thread safe et
async signal safe. Lorsque tu vois que même malloc() ne résiste pas
aux signaux, tu peux assez facilement comprendre qu'un tel
allocateur ne résistera pas non plus !
> Tableau de correspondance
>
> 1 - p o @(1)<p≤@(2)
> 2 - 1 x
> 3 - 3 o
> 4 - 4 o
>
> b a toujours la même adresse pour la zone de mémoire allouée bien que
> l'@ physique n'est pas la même.
physique entre deux threads ? Avec les gestionnaires de signaux ?
C'est bien sur le papier, c'est parfaitement casse-gueule dans un
programme réel.
Et si c'était si facile, on aurait de telles implantations dans des
tas de lib*alloc ou de lib*mem, ce qui n'est pas le cas...
Jo Engo
> Oui, ça marche bien tant que ton ramasse-miette est synchrone
> et que ton code est lui-aussi synchrone. Dès qu'un gestionnaire de
> signal est appelé, ça commence à merdoyer, et je ne parle pas du code
> multithreadé.
Les sémaphores c'est pas fait (que) pour les (mangeurs de) spaghettis,
enfin il me semble. Ne pas confondre synchronisé et synchrone. Et il
faut y songer dès qu'on a 1 gc + 1 autre thread ou 2 thread qui accèdent
au tas, même s'ils n'accèdent pas à la même zone et sans
ramasse-miettes.
JKB
Jo Engo <y...@bidart.net> écrivait :