FF 3 a des bugs de mémoire :( - Page 6

Flanker (./42) :
D'après ce que j'avais pu lire, la consommation mémoire augmente, même si tu ne fais rien...

Si tu as des publicités qui se rechargent automatiquement, il est possible que ce soit normal. Le souci des garbage collector c'est également que ça brouille pas mal les pistes.

Non, rien à voir. Le problème que tu décris serait facile à résoudre, par exemple en faisant un garbage-collect régulièrement...

A ma connaissance, ça ne rend pas la mémoire au système d'exploitation. Ca se contente de faire du ménage en interne pour les allocations suivantes.
C'est en tous cas quelque chose que j'ai lu à plusieurs reprises. Et comme j'ai du mal à voir comment le garbage collector pourrait rendre la mémoire à l'os, ça recoupe assez bien.

squalyl>
tu parles de quelle interaction entre le gc et l'OS? ça m'intéresse vraiment.Parce que dans ma tete a moi, si on fait un truc comme ça, on garde un compteur de references sur chaque élément alloué, et quand la ref est à zéro, on peut libérer le truc.

Hmm, alors un garbage collector ne marche pas comme ça. Trop simpliste, la moindre boucle référentielle bloquerait les objets définitivement. Typiquement, il s'agit plutôt de rechercher les groupes d'éléments non connexes à des éléments nommés.

Cela dit, ça n'a rien à voir avec le problème. Quand le garbage collector libère un objet, la mémoire n'est pas restituée au système d'exploitation. Il se marque juste qu'elle est disponible pour lui pour les prochaines demandes d'allocation.

spectras (./151) :

Non, rien à voir. Le problème que tu décris serait facile à résoudre, par exemple en faisant un garbage-collect régulièrement...

A ma connaissance, ça ne rend pas la mémoire au système d'exploitation. Ca se contente de faire du ménage en interne pour les allocations suivantes.
C'est en tous cas quelque chose que j'ai lu à plusieurs reprises. Et comme j'ai du mal à voir comment le garbage collector pourrait rendre la mémoire à l'os, ça recoupe assez bien.

Oui mais ce qu'il dit (si je comprends bien) c'est qu'en faisant un garbage collect régulièrement, donc en faisant ce ménage en interne, les allocations suivantes ont peu de chances de devoir à nouveau demander de la mémoire supplémentaire à l'OS (puisqu'elles réutiliseront ce qui a été libéré en interne). Donc ce n'est pas un problème très gênant en général (bon après évidemment si tu ouvres 50000 trucs à la fois ça peut bouffer quand même trop de mémoire et tu n'as plus qu'à quitter, mais c'est un cas assez particulier)
Alors que si tu attends qu'il n'y ait plus de mémoire du tout (genre une allocation échoue) pour collecter, là le fait de ne pas pouvoir rendre la mémoire à l'os devient un véritable problème...

spectras (./151) :

Non, rien à voir. Le problème que tu décris serait facile à résoudre, par exemple en faisant un garbage-collect régulièrement...

[...]

Euh tu devrais mettre à qui tu réponds dans l'en-tête du cite, avant que Sally réponde j'avais pas du tout fait attention que c'était à moi que tu répondais ^^ (le truc en javascript pour sauver les citations est pas mal pour éviter ça)

Oui c'est vrai, j'ai tendance à plus me concentrer sur la réponse qu'autre chose ^^

Sally> c'est justement de ce cas là que je parlais en fait. Je disais ça :

En principe, si tu ouvres 200 onglets, tu vas voir le processus Firefox grossir. En les fermant, il ne diminuera pas. En revanche, si tu ouvres à nouveau 200 onglets, sa taille devrait rester à peu près identique. Si c'est le cas, il n'y a pas de fuite de mémoire, c'est un comportement normal, inhérent au manque d'interaction entre les garbage collectors et les systèmes d'exploitation actuels (que ce soit unix, ou windows).

Il n'y a pas que un éventuel problème de garbage collector, mais aussi le fait que FF met beaucoup de chose en cache dans la mémoire pour la restauration des onglets fermés et le retour en arrière rapide en particulier.

D'un autre coté, s'il générait les pages plus vites, il n'aurait pas besoin de les cacher.

Dans un bon gc, il y a une partie faite très régulièrement qui fait ce que vous décrivez : simplement nettoyer la mémoire interne pour la réutiliser, et un second comportement, plus coûteux donc déclenché peu souvent, qui compacte la mémoire pour rendre la partie inutilisée à l'OS.
C'est normal que si un processus consomme énormément de mémoire il ne la rende pas tout de suite.
Mais si ça ne la rend jamais ou extrêmement rarement, c'est que le GC est pourri ou que le système d'exécution rend cette phase trop complexe à mettre en œuvre.
Lorsqu'on compacte le tas, on modifie les pointeurs sur la pile, ce qui n'est pas trivial du tout suivant le modèle d'exécution, par exemple si on mélange plein de langages ou qu'on appelle des modules externes avec des pointeurs. Dans le dernier cas, il est possible soit de tout boxer (passer par une indirection supplémentaire) soit de garder un tas pour les références "externes", mais si ça na pas été prévu dès le départ, c'est le merdier.

./156: certes, mais si les sites Web respectaient mieux les standards du Web, les parseurs seraient moins compliqués (pour s'accomoder des sites Web qui ne respectent rien), et le rendu serait plus rapide
FF est habituellement plus lent qu'Opera (dont le parser supporte moins de sites écrits n'importe comment, on ne peut pas tout avoir ^^), mais plus rapide qu'IE.

PpHd (./156) :
D'un autre coté, s'il générait les pages plus vites, il n'aurait pas besoin de les cacher.   

En fait il ne met pas seulement en cache la page mais son rendu ce qui permet de restaurer une page qui utilise l'AJAX par exemple.

ok