Les correctifs du bogue « Memory Leak » sur GNOME Shell sont disponibles et seront embarqués dans la version 3.28
De l'environnement de bureau
Le 2018-04-23 23:51:46, par Victor Vincent, Expert éminent sénior
Les correctifs du bogue « Memory Leak » détecté sur GNOME Shell et qui se manifeste par l'augmentation de l'espace RAM occupé toutes les minutes seront disponibles dans la prochaine version de GNOME. En effet, depuis le jeudi dernier, les deux Merge Request (MR) de Gitlab qui le résolvent ont été fusionnés. Ces changements après des tests concluants ont été reportés sur la version 3.28 de GNOME. Lorsque le bogue a été constaté, plusieurs utilisateurs l’ont signalé via le ticket 1672297 sur launchpad.net. Le souci a été attribué aux animations du GNOME Shell. En effet, des tentatives de reproduction ont montré que GNOME Shell consommait environ 70 MB de mémoire aussitôt après le démarrage. Ce nombre passe à 95 MB après l’ouverture de menu puis à 250 MB après avoir chargé la grille d'icônes.
Le Garbage Collector est à l’origine du problème. Lorsque des objets en mémoire sont liés par des relations parent/fils, quand on supprime un objet parent il est marqué dans le Garbage Collector. Cette suppression doit normalement entrainer la suppression des objets fils qui lui sont attachés. Contrairement à JavaScript qui trace les objets fils, et par conséquent dont le Garbage Collector supprime tous les objets dépendants, le langage C ne les trace pas. Il conserve uniquement le nombre d’objets dépendants. Ce qui ne permet pas de les supprimer. Après la suppression, le Garbage Collector n’a aucun moyen de lier les objets. Seuls les objets directement dépendants sont supprimés. Le prochain passage du ramasse-miette n’est pas strictement connu, sachant qu’il n’est programmé que lorsque le « toggle reference » d’un GObject contenu dans le GJS passe d’une valeur supérieure à 1 à la valeur 1. Par conséquent, il ne survient que lorsque plusieurs GObject sont empilés. La fuite de mémoire survient à la suite de cet empilement. Formellement, il ne s’agit pas d’une fuite de mémoire, mais plutôt d’un comportement irrégulier de la mémoire.
La solution consiste à programmer le Garbage Collector chaque fois qu’un objet est marqué pour suppression. Cette solution bien qu’ayant un léger impact sur la performance reste efficace. En exécutant fréquemment le Garbage Collector, le nombre d’objets à supprimer est réduit. Autrement dit, le léger impact sur la performance est compensé par le gain en mémoire. Au-delà de cette solution préconisée entre autres par l’expert Georges Stavracas, d’autres améliorations ont été apportées. La première modifie la structure de données sous-jacente des objets JS, ce qui permet de passer d’un algorithme dont la complexité est O(n) à un algorithme dont la complexité est réduite à O(1). La seconde amélioration apportée réduit considérablement le nombre d'allocations de mémoire temporaires. Au-delà de ce bogue sur GNOME, un souci de communication au sein de la communauté a été soulevé. Ainsi, Garnacho déplore que certains utilisateurs considèrent GNOME comme le produit de ses développeurs, créant ainsi une barrière entre eux et les nouveaux contributeurs.
Source : Feaneron
Et vous ?
Voir aussi
Le Garbage Collector est à l’origine du problème. Lorsque des objets en mémoire sont liés par des relations parent/fils, quand on supprime un objet parent il est marqué dans le Garbage Collector. Cette suppression doit normalement entrainer la suppression des objets fils qui lui sont attachés. Contrairement à JavaScript qui trace les objets fils, et par conséquent dont le Garbage Collector supprime tous les objets dépendants, le langage C ne les trace pas. Il conserve uniquement le nombre d’objets dépendants. Ce qui ne permet pas de les supprimer. Après la suppression, le Garbage Collector n’a aucun moyen de lier les objets. Seuls les objets directement dépendants sont supprimés. Le prochain passage du ramasse-miette n’est pas strictement connu, sachant qu’il n’est programmé que lorsque le « toggle reference » d’un GObject contenu dans le GJS passe d’une valeur supérieure à 1 à la valeur 1. Par conséquent, il ne survient que lorsque plusieurs GObject sont empilés. La fuite de mémoire survient à la suite de cet empilement. Formellement, il ne s’agit pas d’une fuite de mémoire, mais plutôt d’un comportement irrégulier de la mémoire.
La solution consiste à programmer le Garbage Collector chaque fois qu’un objet est marqué pour suppression. Cette solution bien qu’ayant un léger impact sur la performance reste efficace. En exécutant fréquemment le Garbage Collector, le nombre d’objets à supprimer est réduit. Autrement dit, le léger impact sur la performance est compensé par le gain en mémoire. Au-delà de cette solution préconisée entre autres par l’expert Georges Stavracas, d’autres améliorations ont été apportées. La première modifie la structure de données sous-jacente des objets JS, ce qui permet de passer d’un algorithme dont la complexité est O(n) à un algorithme dont la complexité est réduite à O(1). La seconde amélioration apportée réduit considérablement le nombre d'allocations de mémoire temporaires. Au-delà de ce bogue sur GNOME, un souci de communication au sein de la communauté a été soulevé. Ainsi, Garnacho déplore que certains utilisateurs considèrent GNOME comme le produit de ses développeurs, créant ainsi une barrière entre eux et les nouveaux contributeurs.
Source : Feaneron
Et vous ?
Voir aussi
-
Le garbage collector est un choix de conception qui a son lot d'inconvénients (latence, non-déterminisme...). Pour la gestion mémoire, C++ propose plutôt le RAII et les smart-pointers (unique_ptr, shared_ptr...).le 24/04/2018 à 23:17
-
sergio_is_backExpert confirméA la lecture de l'article, le problème semble se situer sur l’implémentation GJS (JavaScript bindings for GNOME) et pas au niveau C/C++ (à moins que j'ai mal lu)le 24/04/2018 à 9:18
-
codec_abcMembre confirmé@Steinvikel : Il existe des garbage collector en C++ pour C++ (par exemple Boehm). D'après ce que je comprends c'est que celui utilsé par Gnome semble un peu particulier.le 24/04/2018 à 9:32
-
SteinvikelMembre expertje cite un mémoire sur la "Gestion de cycle de vie des objets" en C++ qui date de 2006 :...Quand on supprime un objet parent il est marqué dans le Garbage Collector. Cette suppression doit normalement entrainer la suppression des objets fils qui lui sont attachés. Contrairement à JavaScript qui trace les objets fils, et par conséquent dont le Garbage Collector supprime tous les objets dépendants, le langage C ne les trace pas. Il conserve uniquement le nombre d’objets dépendants. Ce qui ne permet pas de les supprimer.
" Certains langages comme C, CH, Ada, Pascal et bien d'autres utilisent une libération explicite de la mémoire. L'avantage majeur de cette libération par rapport au Garbage Collector est sans doute l'emploi des pointeurs, outil très important permettant un accès direct à certaines zones mémoires et une utilisation plus optimale de l'espace mémoire.
...
Puisqu'il est une extension de l'ANSI-C (on lui pardonnera cette simplification réductrice ^^' ), C++ utilise une gestion explicite de la mémoire avec les delete, new, free et malloc. Pour M. A. Ellis et B. Stroustrup (affirmation sur des publications de 1990 à 2000), la gestion de mémoire explicite via le Garbage Collector n'est pas une composante du langage C++.
Nous proposons dans notre travail de recherche un outil assurant une gestion implicite de la mémoire basé sur la programmation aspect, notamment avec l'extension AspectC++ qui est un préprocesseur pour un compilateur C++ usuel. L'idée est d'implémenter via AspectC++ des compteurs de références pour les objets nouvellement créés. Il s'agit d'attribuer un compteur de références à un objet, d'incrémenter ce compteur chaque fois qu'un autre objet crée une référence vers le premier objet et de décrémenter ce compteur chaque fois qu'une référence est supprimée. L'objet sera détruit dès que son compteur associé sera à zéro. "
Je lie cette citation à cette partie de l'article :
Je pose alors la question ouverte suivante :Le prochain passage du ramasse-miette n’est pas strictement connu, sachant qu’il n’est programmé que lorsque le « toggle reference » d’un GObject contenu dans le GJS passe d’une valeur supérieure à 1 à la valeur 1. Par conséquent, il ne survient que lorsque plusieurs GObject sont empilés.
Si le garbage collector n'est toujours pas implémenté en C++, n'y a t'il actuellement aucun équivalent (en terme de fiabilité) au garbage collector en C ou C++ pour ce qui est de la suppression de fils et parents ?le 24/04/2018 à 9:01 -
SteinvikelMembre expertJe vais ignorer cette joute plutôt salé, elle me paraît innaproprié.
ça me rassure... j'avais lu des choses sur différents mécanismes de suppression il y un certain temps maintenant, et le C avec ce coté manuel qui me rebute n'en n'est pas capable, cela m'étonnait que C++17 ne puisse pas générer un équivalent (s'il n'existe pas encore en natif) au garbage collector... ça serais un comble pour un langage fortement type avec autant de polymorphisme après 20 années de service. ^^'
" Contrairement à JavaScript qui trace les objets fils, et par conséquent dont le Garbage Collector supprime tous les objets dépendants, le langage C ne les trace pas. Il conserve uniquement le nombre d’objets dépendants. Ce qui ne permet pas de les supprimer. Après la suppression, le Garbage Collector n’a aucun moyen de lier les objets. Seuls les objets directement dépendants sont supprimés. Le prochain passage du ramasse-miette n’est pas strictement connu, sachant qu’il n’est programmé que lorsque le « toggle reference » d’un GObject contenu dans le GJS passe d’une valeur supérieure à 1 à la valeur 1.. "
C'est pour moi également un peut ambigüe, mais à plusieurs on devrait y voir plus clair. : )
Je ne connais ni GObject ni GJS, mais je comprends qu'ici, JS et C sont de concert pour un but commun. De ce que j'en tire, c'est que le JS génère des objet et que l'usage du C ne permet pas (ou le code pas conçu pour ??) au garbage collector (en C ou en JS ??) de faire correctement sont boulot. C'est le C qui fout la merde en ne "traçant pas les dépendances des objets".
A moins que ça implique d'autres tenants et aboutissants que je ne devine pas durant la phase de développement de ce cas de figure (comme communiquer les dépendances de manière détourné ?).
bref. un peu flou techniquement tout ça pour moi, mais l'aspect général du problème était très intéressant. =)le 25/04/2018 à 3:51 -
Le dernier paragraphe de l'article DVP laisse penser à un choix sans optimisation de l'écriture (implémentation) du code source...
C'est surtout gênant avec les scripts en général...
L'impact sur la mémoire RAM était le même en 32 bits et 64 bits ?le 24/04/2018 à 6:49