Servo: Empêcher la fuite de mémoire de PerformanceObserver

La théorie de la performance prend étant maintenue dans la file d'attente des tâches semble plausible.

cc @asajeffrey @jdm Je pense que c'est plausible, et aussi que ce n'est pas ce qui s'est passé dans ce cas précis, et qu'à la place nous divulguons PerformanceObserver puisqu'ils ne sont jamais supprimés de Performance (qui lui-même n'était pas défini sur None non plus), à moins que le script n'appelle https://github.com/servo/servo/blob/6297fa582ac4c870e4a8d16cd261da6ede14191d/components/script/dom/performanceobserver.rs#L131

Nous pourrions envisager de modifier la structure de stockage des observateurs, afin qu'ils ne soient maintenus en vie que par leur PerformanceObserverCallback dans le script (ils seraient donc supprimés si le script annule le rappel, je pense).

J'ai besoin de m'y intéresser davantage.

Cela pourrait ressembler à quelque chose comme : nous pourrions séparer l'objet DOM PerformanceObserver d'un PerformanceObserverImpl , ce dernier gardant une trace de choses comme DOMPerformanceEntryList et d'autres "données", tandis que le L'objet DOM ne serait qu'un wrapper autour du rappel.

Ensuite, le global pourrait conserver une référence forte au Impl , et un Weak<PerformanceObserver> qui serait supprimé si le rappel du script était défini sur None .

Ensuite, le global pourrait exécuter un point de contrôle périodique comme c'est le cas pour les ports de message à https://github.com/servo/servo/pull/23637/files#diff -59d233642d0ce6d687484bdd009e1017R484

D'un autre côté, je ne suis pas vraiment sûr que le code sur https://gist.github.com/kanaka/119f5ed9841e23e35d07e8944cca6aa7 crée des observateurs, ce qui pourrait invalider la logique ci-dessus (au moins en ce qui concerne la fuite perçue lors de l'exécution de ce script ). Il faudra regarder de plus près.

Ah ok, même s'il n'y a pas d'observateurs définis, nous tamponnons toujours souvent l'entrée sur https://github.com/servo/servo/blob/39bd45529d6ef3eea8e0eeef77d0294e0db1b02c/components/script/dom/performance.rs#L244

Et cela se produit par exemple à chaque fois que le script effectue une récupération : https://github.com/servo/servo/blob/7490dd6f0deafc8192126a88a8a6f75c100e5d71/components/script/network_listener.rs#L65

utilisé par exemple par le chargeur de feuille de style (utilisé dans le script de débogage qui fuyait la documentation) : https://github.com/servo/servo/blob/799490a02e9bea575bf34c39f045ef0883539f05/components/script/stylesheet_loader.rs#L233

Lui-même appelé par fetch à https://github.com/servo/servo/blob/9bba14cb438cf5ac08945bb8fbb5a0f31d43fcbe/components/net_traits/lib.rs#L260

Ok donc ceci https://github.com/servo/servo/pull/24109 corrige la cause réelle de la fuite et supprime les modifications précédentes qui définissent Performance dans son ensemble à None .

La cause de la fuite perçue était en effet le tampon, car aucun observateur de performance n'a été créé.

Laissant celui-ci ouvert, car je pense que nous devrions toujours résoudre le problème avec les observateurs de performances, qui fuient à moins que le script n'appelle Disconnect sur eux. Voir https://github.com/servo/servo/issues/24074#issuecomment -526026684, le correctif consisterait à trouver un moyen de stocker les observateurs tout en leur permettant d'abandonner lorsque le script ne conserve pas de référence à leur rappel .