Geckozone

bigbernie a écrit :Une chose m'intrigue. La non liberation de memoire parfois. Je croyais que ça venait uniquement de logiciels mal programmés ?
Dans le temps, je dirais au moins 10 ans, c'etait assez courant. Il existait a cette epoque ancienne des logiciels de recuperation automatique de memoire programmable et aussi pour la quantite dont il fallait forcer la liberation
Ou alors creer un script VBS freemem=space (xxx)
On pouvait aussi modifier le registre afin de forcer la liberation de la ram plus utilisee.
Sans devoir rebooter bien sur.

En JS, le développeur n'a pas à s'occuper de la gestion de la mémoire. C'est au garbage collector (ramasse miette en français) de déterminer si une allocation est potentiellement utile où inutile.

MacIntoc a écrit : En JS, le développeur n'a pas à s'occuper de la gestion de la mémoire. C'est au garbage collector (ramasse miette en français) de déterminer si une allocation est potentiellement utile où inutile.

En fait c'est une légende: en js le développeur doit aussi se préoccuper de la gestion de la mémoire. Parce que le ramasse-miettes, s'il récupère ce qui n'est plus utilisé, il est important que les choses plus utiles ne soient plus utilisées par le développeur.

Il y a des extensions qui gardent en mémoire plein d'objets inutiles. Dans des historiques, dans des structures de données oubliées mais toujours accessibles. La même chose pour la quantité de mémoire utilisée, le développeur js doit s'avoir quelle quantité de mémoire va utiliser son script. Sans quoi ça va être le bronx.

C'est d'ailleurs un des problèmes du js ou du java: ces langages donnent l'impression que les développeurs n'ont plus à maîtriser la gestion de la mémoire. C'est parfaitement faux. Cela leur permet juste de ne pas avoir à faire de déallocation explicite, mais pour leur reste il faut exactement la même maîtrise de la gestion mémoire. C'est pas parce qu'il y a un ramasse-miette qu'il faut pas connaître l'utilisation mémoire d'un algorithme (O(n), O(log n) O(n^2), ...). C'est pas parce qu'il y a un ramasse-miette qu'il ne faut pas faire attention à ce que les objets inutiles n'aient plus de référence vers eux.

En fait là où le développeur C++ se disait: je dois mettre un delete, le développeur JS (ou Java) doit se dire: ici, c'est bon, l'objet n'est plus accessible. Ça ne change pas donc grand chose pour le développeur (sauf pour des scripts très court, mais pas pour des extensions ou des web apps ou des sites un tantinet complexe).

Y'a pas de miracle un programmeur doit maîtriser la gestion de la mémoire, même s'il a un ramasse-miettes! Il faut pas oublier de les faire tomber ces miettes.

Le principal avantage des langages à ramasse-miettes, c'est qu'une certaine mauvaise gestion de la mémoire ne fait plus cracher le navigateur (avec les problèmes de sécurité que cela peut entraîner); c'est utile, mais c'est de loin pas l'élément le plus compliqué de la gestion de la mémoire.

Je me souviens qu'avec IE ≤ 6, dans les gros projets JS, il était recommandé de "détruire" soi-même les variables devenues inutiles en leur assignant la valeur null sinon, la conso mémoire de IE montait en flêche

teoli2003>Faut comprendre mon message dans le contexte de celui de bigbernie.

MacIntoc a écrit :teoli2003>Faut comprendre mon message dans le contexte de celui de bigbernie.

Oui, bien sûr; cela ne t'était pas directement adressé, je voulais juste préciser pour d'autres pour qui ce n'est pas forcément évident.

Bobe a écrit :Je me souviens qu'avec IE ≤ 6, dans les gros projets JS, il était recommandé de "détruire" soi-même les variables devenues inutiles en leur assignant la valeur null sinon, la conso mémoire de IE montait en flêche

S'il est dans le scope global et que tu veux que le ramasse-miettes s'en occupe, c'est mieux, c'est même exigé. Et pas seulement dans IE ≤ 6, partout. Le ramasse-miettes ne détecte que les objets sans référence, tant que tu en gardes, il ne va pas les récupérer.

Le scope global se termine (et donc les références sont supprimées) lorsque l'on quitte le document seulement. Si tu fais une web app, un document à très longue durée de vie, il faut donc que tu gères le scope global au plus près, sans quoi tu as un quasi-leak.

Par contre dans les fonctions (l'autre scope définissant la durée de vie des variables), ce n'est pas nécessaire (je sais pas par contre pas pour IE ≤ 6 où je ne m'en suis jamais préocuppé), puisqu'en quittant la fonction ces variables sont effacées (et donc les références vers les objets qui, s'ils n'en ont pas d'autres, seront supprimés lors du prochain ramassage de miettes).

C'est encore pire dans le cas d'une extension puisque le scope global est à peu près celui du navigateur. (Donc éternel: le quasi-leak se confond avec un véritable leak)

Edit: Bobe, je précise que ma réponse ne sous-entend pas que tu ne le savais pas. Je rebondis sur ton message pour préciser une chose que d'autres ne savent sûrement pas, hein!

http://ddweerasiri.blogspot.com/2011/03 ... hrome.html

teoli2003 a écrit : Par contre dans les fonctions (l'autre scope définissant la durée de vie des variables), ce n'est pas nécessaire (je sais pas par contre pas pour IE ≤ 6 où je ne m'en suis jamais préocuppé), puisqu'en quittant la fonction ces variables sont effacées (et donc les références vers les objets qui, s'ils n'en ont pas d'autres, seront supprimés lors du prochain ramassage de miettes).

yep, c'est avec les références circulaires d'objets dans les scopes de fonctions que le GC d'IE 6 avait beaucoup de mal. voir par exemple :
http://foohack.com/2007/06/msie-memory-leaks/

teoli2003 a écrit : Edit: Bobe, je précise que ma réponse ne sous-entend pas que tu ne le savais pas. Je rebondis sur ton message pour préciser une chose que d'autres ne savent sûrement pas, hein!

Pas de problème ^^

Mouais, partir de Firefox à 150Mo, ça fait pas très sérieux comme étude. De plus, Firefox 3.6 est plutôt du genre dépassé...

L'idée est bonne (je dirai même qu'elle m'intéresserait pas mal - oui, parce que je ne le ferai pas moi-même- ), mais il faudrait partir de 2 navigateurs vierges d'addons (à part Flash), et prendre Firefox 5 et Google 13 (aujourd'hui).

Bobe a écrit : yep, c'est avec les références circulaires d'objets dans les scopes de fonctions que le GC d'IE 6 avait beaucoup de mal. voir par exemple :
http://foohack.com/2007/06/msie-memory-leaks/

Ah oui, d'accord. Je savais pas qu'IE6 utilisait cela.

Alors pour ceux que cela intéresse. La technologie des ramasse-miettes n'est pas "facile" : la méthode naïve est de compter les références (les liens vers un objet), lorsqu'il n'y en a plus, c'est que l'objet n'est plus utilisé et le ramasse-miette lorsqu'il parcourera tous les objets s'il en voit un avec 0 liens vers lui, l'effacera. C'est une manière assez pratique car on peut tout à fait utiliser un fil en arrière-plan pour le faire car un objet qui est à 0 liens n'en récupérera jamais. Ainsi on a pas besoin d'arrêter le navigateur lorsque le ramasse-miette tourne. De plus l'algorithme de marquage est simple (O(1) en terme algorithmique.

Le gros hic de cette manière de faire, c'est que cela ne permet pas de trouver tous les objets inutiles. En effet si on a une référence circulaire: A -> B -> A qui n'est liée par personne d'autres, elle devrait être effacée, mais ne le sera jamais avec l'algorithme de comptage puisque A a un lien vers lui (depuis B) et B a un lien aussi (depuis A).

C'est pour cela que dès les années 1960 (et le langage Lisp — surnommé Langage idiot saturé de parenthèses), un nouveau type de ramasse-miettes a été inventé: les GC mark-and-sweep (marquer-puis-effacer). Comme le nom l'indique il y a deux phases: une phase où il parcourt tous les liens depuis les objets globaux et il y marque tous les objets atteints. Tout ceux qui sont marqués ne doivent pas être effacer. Puis une seconde phase où il parcourt séquentiellement (par ordre de création par exemple) tous les objets js et efface ceux qui ne sont pas marqués. Ainsi pas de soucis avec les cycles, pas de fuites mémoires.

Par contre cet algorithme, outre une complexité plus grande (et donc une utilisation processeur un peu plus grande) a un inconvénient: pendant qu'il a lieu, on ne peut ni créer ni effacer des objets js. On arrête le monde (d'où le nom de ces ramasse-miettes: stop-the-world). Firefox a un tel algorithme. La plupart du temps on ne remarque pas les pauses GC, mais ces derniers temps avec la vidéo ou l'apparition de jeux et d'animations js qui nécessite une grosse fluidité et créent beaucoup plus d'objets js, c'est devenu un problème. Pour le diminuer, Firefox 4 a diviser les objets js en compartiments indépendant (typiquement un par onglet, plus quelques autres). Ainsi chaque compartiment nécessite une pause plus courte pour être nettoyé, et les compartiments peu modifié y passent moins souvent. (Cela a un autre avantage, il permet de connaître la consommation mémoire par onglet, affiché dans about:memory dès Firefox 7, en Aurora, maintenant; cadeau bonus du travail fait pour Firefox 4!)

Firefox migre désormais vers un nouveau ramasse-miettes, toujours mark-and-sweep mais plus stop-the-world. C'est en cours et la première phase devrait dans Firefox 8 ou Firefox 9 (C'est le Bug 641025 —[meta] Incremental GC).

Dès que ce sera prêt, les pauses ne devraient plus être ressenties. Pour une animation, si auparavant elle faisait 30 images/s mais tomber à 0 images/s pendant 200 ms toutes les 40s, avec le nouveau elle fera peut-être 29 images/s mais en permanence). Ce sera bien mieux.

Voilà, j'espère que cela vous a aider. Gardez néanmoins à l'esprit que l'on n'a fait que survoler la problématique: le ramasse-miettes a des incidences sur le cache, le paging, la localité du code, l'utilisation CPU, l'utilisation mémoire, la fragmentation et la sécurité et bien sûr la stabilité: le moindre bug dans le ramasse-miettes fait crasher (souvent) le navigateur.

Il y a plusieurs développeurs de Firefox qui ne s'occupent que du ramasse-miettes. C'est important et pas très visible pourtant.

@Teoli> Il me semble qu'aucun ramasse miettes qui ose se nommer ainsi ne fonctionne par comptage de référence. Ce mécanisme est généralement plutôt utilisé pour ce qu'on appelle les pointeurs intelligent.

Si les références circulaires ne sont pas gérées, on reste obligé de faire manuellement les désallocations sous peine de problème.
Au mieux ça peut éviter certains oublis mais au final c'est plus dangereux qu'utile.

Uther a écrit :@Teoli> Il me semble qu'aucun ramasse miettes qui ose se nommer ainsi ne fonctionne par comptage de référence. Ce mécanisme est généralement plutôt utilisé pour ce qu'on appelle les pointeurs intelligent.

Oui, mais les cycles peuvent être vicieux. A->B->A si B n'est pas un objet javascript... Il faut que le ramasse-miette soit adapté à ce genre de choses (qui arrivent dans les navigateurs). Même un algorithme mark-and-sweep peut louper des cycles hybriques comme ceci. (C'était le cas dans IE6 ou dans certains Firefox ≤ 3; je pense d'ailleurs qu'il peut encore avoir des cas où Firefox détecte mal les cycles, mais probablement pas en js)

Et des objets non-javascript accédés depuis le javascript il y en a dans le navigateur: les objets DOM ou XPCOM par exemple.

Ma description reste une simplification: mais un navigateur moderne est un des programmes les plus complexes qui tourne sur un PC.