Journal Des nouvelles d'Electrolysis

41
25
août
2014

Voici quelques nouvelles du projet Electrolysis de Mozilla Firefox.

Pour ceux qui se le rappelle, Electrolysis est le projet de rendre Firefox plus multi-tâche, avec, entre autre, une séparation des processus par onglets (et bien d'autres).

Ce projet avait été abandonné une première fois, pour finalement être repris.

Le travail continue, et la fin du mois du juillet a vu une séance de test des modules complémentaires pour faire avancer les développeurs sur ce sujet. À l'issue de cette journée, 15 rapports de bogues furent ouverts, et une vingtaines de modules ont été notés comme fonctionnant parfaitement.

L'effort sera priorisé en fonction du nombre d'utilisateurs des modules d'après cette page.

La version M1 d'e10s (le nom raccourci d'Electrolysis), dont le but est de pouvoir être utilisée par un utilisateur λ dans les nocturnes, mais en étant désactivé par défaut, n'est plus qu'à 1 bogue de se faire.

Un carnet de route a été établi permettant d'établir un peu le travail restant.

Désormais, e10s permet une expérience proche de la normale, en utilisant des processus séparés par onglets, et en utilisant 1 processus de rendu par onglet. Néanmoins, il est, par exemple, impossible d'imprimer, ou de lire un fichier PDF avec le lecteur intégré.

Le projet est donc bien vivant et avance sûrement.

Le mot de la fin : certains voudraient qu'Electrolysis soit prêt (dans Aurora par défaut ? ou en stable ? À vous de spéculer !) pour fêter l'anniversaire de la première décennie de la version 1.0 de Mozilla Firefox le 9 novembre prochain.

  • # Consommation mémoire

    Posté par (page perso) . Évalué à 10.

    Avoir un système à la Chrome ne va-t-il pas mener à un consommation mémoire à la Chrome? (c'est à dire plus importante avec un grand nombre d'onglet)
    Ça m'inquiète un peu.

    • [^] # Re: Consommation mémoire

      Posté par (page perso) . Évalué à 3.

      Faudra voir. Au pire, il y aura peut-être une extension pour rétablir l'ancien comportement (c'est 1 preférence à desactiver, ou un attribut XUL à enlever sur chaque onglet, pas sorcier à priori).

    • [^] # Re: Consommation mémoire

      Posté par (page perso) . Évalué à 1.

      Tu veux dire plus de 763Mio consommés pour 11 onglets ouverts et une poignée d'extensions ? C'est possible ça ? J'utilise Firefox pour de multiples raisons, mais la vitesse de Chromium me manque.

      Et oui, le moteur JS de Firefox est plus rapide dans les tests SunSpider mais l'Autre est plus réactif à l'utilisation.

      Du coup, j'attends avec impatience cette amélioration histoire d'éviter de freezer tout le navigateur quand un bout de JS récalcitrant fout le boxon dans un onglet indéterminé.

      • [^] # Re: Consommation mémoire

        Posté par . Évalué à 7.

        Il a parlé de mémoire allouée, aucunement de vitesse.

        • [^] # Re: Consommation mémoire

          Posté par (page perso) . Évalué à 2.

          Pourtant, on a souvent un compromis entre massacrer la mémoire au profit de la vitesse ou au contraire faire faire plus de boulot au processeur pour économiser de la mémoire. Au hasard, les fonctions trigo sont souvent sous forme de LUT sur les systèmes embarqués.

          Mais c'est vrai que formellement, il ne parlait que de mémoire allouée :)

          • [^] # Re: Consommation mémoire

            Posté par . Évalué à 4.

            Il a aussi un compromis entre besoin en ressources et temps de développement :)

            Please do not feed the trolls

            • [^] # Re: Consommation mémoire

              Posté par . Évalué à 7.

              chrome a trouvé un bon moyen pour limiter la consommation de la mémoire (et l'utilisation des onglets) : au delà d'une douzaine d'onglets, on n'arrive plus à lire leur titre, du coup ça dissuade de les utiliser.

              Et effectivement il y a autant de processus que d'onglets chromium, par contre si je tue un processus (kill) ou si je le "termine" (dans ksysguard), ça tue tous les autres. Avec une moyenne de 65 Mo par onglet, pour 12 onglets ça me prend 500 Mo de ram. Dans Firefox avec 1400 onglets (!!) ça me prend "seulement" 2 Go (mais ils ne se rechargent que quand on clique dessus, ce qui limite la consommation)

              • [^] # Re: Consommation mémoire

                Posté par . Évalué à 8.

                ça me prend "seulement" 2 Go (mais ils ne se rechargent que quand on clique dessus, ce qui limite la consommation)

                Sous Firefox on peut configurer de telle manière que tous les onglets soient chargés au démarrage, on ne peut pas faire la configuration inverse pour Chrome ? Je connais pas du tout parce que je suis satisfait de Firefox, mais j'ai du mal à croire que Chrome n'offre pas cette possibilité.

                Dans Firefox avec 1400 onglets (!!)

                Rassure moi c'était un test ? Ou bien tu conserves en permanence plus de 1000 onglets ouverts ?

  • # [référence nécessaire]

    Posté par (page perso) . Évalué à 6.

    Lien oublié :

    certains

  • # Process VS thread

    Posté par (page perso) . Évalué à 2.

    Question bête : pourquoi utiliser un process par onglet plutôt qu'un thread par onglet ?

    Je suis sûr qu'il y a une bonne explication pour Electrolysis, mais je ne la connais pas. Merci de m'éclairer ;)

    blog.rom1v.com

    • [^] # Re: Process VS thread

      Posté par . Évalué à 9.

      Deux process sont isolés par l'OS, donc pas de mémoire commune. Pas de risque de pollution de l'un par l'autre.

      Je suppose qu'il y a un process "maître" qui gère l'interface graphique et échange les informations à afficher entre les process. Ce processus maître pourrait même dans une certaines mesure modifier la priorité des process en fonction de l'état visible ou non.

      • [^] # Re: Process VS thread

        Posté par (page perso) . Évalué à 1. Dernière modification le 25/08/14 à 17:42.

        Deux process sont isolés par l'OS, donc pas de mémoire commune. Pas de risque de pollution de l'un par l'autre.

        Certes, mais pour l'instant c'est mono-process mono-thread, non?
        Pourquoi passer directement en multi-process et pas mono-process multi-thread? Ce compromis ne pourrait-il pas économiser la consommation mémoire?

        blog.rom1v.com

        • [^] # Re: Process VS thread

          Posté par . Évalué à 6.

          Ce compromis ne pourrait-il pas économiser la consommation mémoire?

          Si, encore que le code n'est pas forcément dupliqué, il peut être en lecture, exécution à la même adresse réelle, mais pas virtuelle.

          Le problème de base est la gestion des failles javascript permettant d'interagir avec d'autres onglets, voir d'isoler l'exécution des plug'in flash, java, activeX… pour qu'un seg fault ne fasse disparaître qu'un onglet et pas toute l'application, avec du travail non terminé sur un onglet.

          • [^] # Re: Process VS thread

            Posté par . Évalué à 6.

            À noter que les plugins sont déjà dans des process séparés (par définition) et que firefox est déjà résistant à leur crash.

        • [^] # Re: Process VS thread

          Posté par . Évalué à 9.

          C'est une question de securite, ainsi qu'une question de reliabilite.

          En mode 'plusieurs process' :
          - Si un onglet crash, tes autres onglets ne sont pas affectes
          - Si il y a une faille touchant un onglet, les autres onglets ne sont pas affectes non plus (une fois qu'il y aura une sandbox)

          • [^] # Re: Process VS thread

            Posté par (page perso) . Évalué à 7.

            Au final, cela reviens à dire que les windows manager auraient du gérer les onglets depuis longtemps. Cela me rappelle un débat une quinzaine d'année en arrière ;-)

            • [^] # Re: Process VS thread

              Posté par . Évalué à 3.

              Consommation en ressource vs architecture 'saine' le débat est éternel..
              J'aime beaucoup Chrome mais je l'ai abandonné sur un PC qui n'a "que" 4 Go de RAM à cause de sa consommation mémoire, se faire 'swapper' le bureau c'est très désagréable..

            • [^] # Re: Process VS thread

              Posté par . Évalué à 5.

              C'est plus complique que ca. Il faut tout un systeme de sandbox et broker aussi pour permettre au processus s'occupant du rendering de demander acces au FS pour y ecrire ou lire un fichier par exemple. C'est pas juste une histoire d'onglet et d'affichage.

              • [^] # Re: Process VS thread

                Posté par (page perso) . Évalué à 3.

                Oui, je me souviens aussi de l'intégration de systrace à OpenBSD qui permet de réduire les attaques avec un système assez simple.

                Je ne dis pas que c'est parfait mais je pense personnellement que c'était la bonne voie, quitte à l'améliorer par la suite.

          • [^] # Re: Process VS thread

            Posté par . Évalué à 10.

            C'est une question de securite, ainsi qu'une question de reliabilite.

            s/reliabilité/fiabilité.

            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

        • [^] # Re: Process VS thread

          Posté par (page perso) . Évalué à 9.

          pour l'instant c'est mono-process mono-thread, non?

          Mono process, oui, mono-thread, non ! Depuis toujours Firefox utilise les threads pour diverses choses, fort heureusement, sinon l'interface serait gelée au moindre octet reçu ou envoyé. Et ces dernières années il y a eu d'énormes effort pour tout faire en asynchrone et threadé (comme toutes les manipulations de fichiers, les calculs de rendu etc..). Et coté HTML/Js, les web worker ne datent pas d'hier ;-)

          • [^] # Re: Process VS thread

            Posté par . Évalué à 1.

            Mono process, oui, mono-thread, non ! Depuis toujours Firefox utilise les threads pour diverses choses, fort heureusement, sinon l'interface serait gelée au moindre octet reçu ou envoyé.

            D'ailleurs xmlhttprequest ne serait pas possible sans thread !

            • [^] # Re: Process VS thread

              Posté par . Évalué à 7.

              • [^] # Re: Process VS thread

                Posté par . Évalué à 1.

                Et les boucles événementielles délèguent bien souvent à un thread pool histoire de ne pas se blo

                • [^] # Re: Process VS thread

                  Posté par . Évalué à 4. Dernière modification le 27/08/14 à 00:42.

                  Sauf nodejs, twisted, libevent,…

                  Tu n’as pas besoin de threads pour ne pas te bloquer : asyncio + select/epoll/autre mécanisme similaire fourni par l’OS.

                  De même, si Go peut utiliser plusieurs threads il peut aussi très bien tourner avec GOMAXPROCS=1 sans pour autant bloquer bêtement toutes les goroutines sur une IO/synchronisation…

                  • [^] # Re: Process VS thread

                    Posté par . Évalué à 0.

                    Et dire que je m'imaginais qu'environ 99% des API disponibles sur Terre étaient synchrones…

                    • [^] # Re: Process VS thread

                      Posté par . Évalué à 2.

                      Dans le monde javascript (puisqu’on parle de XMLHttpRequest à la base) le synchrone est l’exception, l’asynchrone la règle.

      • [^] # Re: Process VS thread

        Posté par . Évalué à 7.

        Il y a aussi la question de la résilience. Si un processus plante (accès mémoire interdit par exemple), l'OS va l'arrêter.
        Dans le cas d'un navigateur ayant un seul processus et un thread par onglet, tout le navigateur plante.
        Dans le cas d'un navigateur ayant un processus par onglet, seul celui en erreur plante. Si le processus qui gère la fenêtre est bien fait, il peut simplement avertir l'utilisateur.

        Avoir plusieurs processus complique la gestion, ajoute un léger surcoût pour les communications entre processus (gestion du cache partagé, cookies etc) mais est la seule solution pour avoir une isolation suffisante.

        C'est vraiment une bonne chose que le navigateur lui-même soit encore développé, il y a des timides développements pour wayland aussi. Bientôt Firefox aura rattrapé son retard sur Epiphany.

        • [^] # Re: Process VS thread

          Posté par . Évalué à 1.

          Dans le cas d'un navigateur ayant un seul processus et un thread par onglet, tout le navigateur plante.

          Il y a toujours possibilité de traiter le segfault, ma prog système est un peu rouillée mais ça doit être faisable de trouver quel thread mange de la colle après un segfault et corriger le problème.

          Please do not feed the trolls

          • [^] # Re: Process VS thread

            Posté par . Évalué à 3.

            Bah le truc c'est qu'après un segfault tu n'as aucune idée de l'état dans lequel se trouve ton processus et tu n'a aucun moyen de revenir proprement dans un état stable et connu, dans ce cas il vaut mieux tout stopper avant d'accumuler les dégâts collatéraux.

        • [^] # Re: Process VS thread

          Posté par . Évalué à 5.

          Bientôt Firefox aura rattrapé son retard sur Epiphany.

          Y a encore beaucoup trop d'options pour ça.

  • # Comment l'activer ?

    Posté par . Évalué à 4.

    Pour les utilisateurs de nightly qui se demande comment activé cette fonctionnalité, c'est simple :
    - Soit dans le menu "file" vous cliquez sur "New e10s window". Cela va ouvrir une nouvelle fenêtre avec ce comportement.
    - Soit dans le "about.config" vous surchargez "browser.tabs.remote.autostart" à "true". Au prochain démarrage, firefox se comportera de ce manière par défaut (avec la possibilité d'ouvrir une fenêtre classique dans le menu "file").

    Par contre, cela n'a pas l'air exempt de bugs. Par exemple, je ne peux pas m'authentifier sur DLFP avec e10s.

    • [^] # Re: Comment l'activer ?

      Posté par (page perso) . Évalué à 4.

      Par exemple, je ne peux pas m'authentifier sur DLFP avec e10s.

      Tu peux déposer un bug ?

    • [^] # Re: Comment l'activer ?

      Posté par (page perso) . Évalué à 1.

      Pour ma part je n’ai jamais rien qui s’affiche, mais on peut quand même naviguer si on connaît par cœur le site :D

      Et sinon j’ai aussi un message qui me dit d’activer layers.offmainthreadcomposition.enabled dans les préférences pour ouvrir un nouvel onglet avec la fonctionnalité effectivement activée.

      Love – bépo

  • # comment ça fonctionne ?

    Posté par . Évalué à 2.

    Salut,

    Question bête, comment fait on communiquer deux processus ensemble dans ce cas de figure ?

    Deux threads je vois bien via des messages. Mais deux processus ?
    Les fois où j'ai fait cela, les messages passaient par des feeds à base de stoud/stderr, et ce n'était pas hyper pratique, voir même carrément dark age….
    des apis/proto spécifiques ?

    • [^] # Re: comment ça fonctionne ?

      Posté par . Évalué à 2. Dernière modification le 29/08/14 à 12:27.

      Tu as plein de mécanismes :

      • Mémoire partagée
      • Pipes anonymes
      • Sockets unix
      • Partage de descripteurs de fichiers
      • msgsnd/mq_send

      Et j’en oublie certainement. Tu as aussi des API multiplateformes comme 0MQ (même si de base la plupart des mécanismes ci-dessus se retrouvent de toute façon sur tous les OS majeurs).

      • [^] # Re: comment ça fonctionne ?

        Posté par (page perso) . Évalué à 2.

        Tu peux même communiques via TCP/IP entre machines distantes (Par exemple, Pulsar pour Python permet ça)

        Bref, l'idée, c'est d'envoyer des messages, alors tu peux faire comment tu veux.

      • [^] # Re: comment ça fonctionne ?

        Posté par (page perso) . Évalué à 3.

        Tu as oublié Dbus, bientôt dans votre noyau favoris.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: comment ça fonctionne ?

          Posté par . Évalué à 1.

          Et aussi toutes les API non multi-platformes (même si quelque part ça utilise à une fonctionnalité du mentionnée ci-dessus ou similaire).

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.