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.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.
La gestion de memoire de FF a donc des problemes ?
Re: La gestion de memoire de FF a donc des problemes ?
Re: La gestion de memoire de FF a donc des problemes ?
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.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.
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.
La liberté n'est jamais accordée de bon gré par l'oppresseur; elle doit être exigée par l'opprimé (Martin Luther King).
Les convictions sont des ennemis de la vérité plus dangereux que les mensonges. (Nietzsche).
Native Mozillian.
Les convictions sont des ennemis de la vérité plus dangereux que les mensonges. (Nietzsche).
Native Mozillian.
Re: La gestion de memoire de FF a donc des problemes ?
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
« La vie d’un geek est un combat perpétuel contre l’imperfection »
Re: La gestion de memoire de FF a donc des problemes ?
teoli2003>Faut comprendre mon message dans le contexte de celui de bigbernie.
Re: La gestion de memoire de FF a donc des problemes ?
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.MacIntoc a écrit :teoli2003>Faut comprendre mon message dans le contexte de celui de bigbernie.
La liberté n'est jamais accordée de bon gré par l'oppresseur; elle doit être exigée par l'opprimé (Martin Luther King).
Les convictions sont des ennemis de la vérité plus dangereux que les mensonges. (Nietzsche).
Native Mozillian.
Les convictions sont des ennemis de la vérité plus dangereux que les mensonges. (Nietzsche).
Native Mozillian.
Re: La gestion de memoire de FF a donc des problemes ?
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.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
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!
La liberté n'est jamais accordée de bon gré par l'oppresseur; elle doit être exigée par l'opprimé (Martin Luther King).
Les convictions sont des ennemis de la vérité plus dangereux que les mensonges. (Nietzsche).
Native Mozillian.
Les convictions sont des ennemis de la vérité plus dangereux que les mensonges. (Nietzsche).
Native Mozillian.
Re: La gestion de memoire de FF a donc des problemes ?
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 :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).
http://foohack.com/2007/06/msie-memory-leaks/
Pas de problème ^^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!
« La vie d’un geek est un combat perpétuel contre l’imperfection »
Re: La gestion de memoire de FF a donc des problemes ?
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).
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).
Re: La gestion de memoire de FF a donc des problemes ?
Ah oui, d'accord. Je savais pas qu'IE6 utilisait cela.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/
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.
La liberté n'est jamais accordée de bon gré par l'oppresseur; elle doit être exigée par l'opprimé (Martin Luther King).
Les convictions sont des ennemis de la vérité plus dangereux que les mensonges. (Nietzsche).
Native Mozillian.
Les convictions sont des ennemis de la vérité plus dangereux que les mensonges. (Nietzsche).
Native Mozillian.
Re: La gestion de memoire de FF a donc des problemes ?
@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.
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.
Le monde se divise en 10 catégories : ceux qui comptent en binaire et ceux qui ne comptent pas en binaire.
Re: La gestion de memoire de FF a donc des problemes ?
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)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.
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.
La liberté n'est jamais accordée de bon gré par l'oppresseur; elle doit être exigée par l'opprimé (Martin Luther King).
Les convictions sont des ennemis de la vérité plus dangereux que les mensonges. (Nietzsche).
Native Mozillian.
Les convictions sont des ennemis de la vérité plus dangereux que les mensonges. (Nietzsche).
Native Mozillian.
Qui est en ligne ?
Utilisateurs parcourant ce forum : Google [Bot] et 1 invité