Luca Annunziata

Mozilla: più processi per Firefox

Lo sviluppo del browser si avvia verso il multithreading più spinto. Come i concorrenti hanno fatto da un po'. E magari ci sarà anche più spazio per i 64bit

Roma - È arrivato il momento di fare sul serio: se fino a questo punto gli sviluppatori di Firefox hanno concentrato i loro sforzi nel tenere separati i plugin e le parti più gravose del browser dal core del software stesso, presto ogni singola finestra, scheda e attività del Panda Rosso sarà sostenuta dal suo processo indipendente. A dirlo è Chris Blizzard di Mozilla Corporation, che in un lungo post sul blog aziendale ha illustrato i vantaggi e il percorso che aspetta ora lui stesso e tutta la community.

Se Chrome, Safari e quasi tutta la concorrenza sono già approdati al paradigma del "divide et impera" per tenere separati (e indipendenti) i vari componenti del browser, per Firefox il vero cammino inizia adesso: un semplice meccanismo che migliori la garbage collection, ovvero la gestione intelligente delle aree di memoria non più utilizzate, non basta a tenere a freno gli appetiti smisurati per la RAM del browser. Nonostante i miglioramenti riscontrati nel passaggio a Firefox 4 e 5 (e quelli previsti per la versione 6 e soprattutto per la 7), si impone un passo in più e un cambio di strategia: e Blizzard si assume il compito di spiegare quali saranno i passaggi fondamentali di questa transizione.

Innanzi tutto, i benefici di questo approccio multithreading: meno memoria impegnata, maggiore reattività dell'interfaccia, possibilità di sfruttare appieno le caratteristiche dei moderni processori multi-core e un comportamento più lineare e prevedibile. Senza contare che, tenendo separati i processi di ciascuna scheda, finestra e plugin, si può contare anche su una maggiore stabilità complessiva del software (se si blocca una componente non casca il mondo: ci si limita a terminare quella parte, e il resto continua a funzionare senza intoppi), e si limitano i rischi di pericoli in arrivo dalla Rete tramite una sandbox analoga a quella che da sempre contraddistingue Google Chrome.
I tecnici di Mozilla fanno sul serio: hanno sviluppato degli strumenti di misurazione delle prestazioni appositamente disegnati per valutare i propri progressi, e hanno stabilito a priori tempi di risposta precisi che intendono far rispettare alla interfaccia e quindi al browser nel suo complesso. Se 50 millisecondi sembrano un buon traguardo, di certo il gradimento degli utenti di Firefox crescerà per un software che nel complesso dovrebbe risultare molto più fluido, costante e naturale nel suo funzionamento.

Alcune delle innovazioni fin qui descritte, e più ampiamente trattate da Blizzard, non sono destinate a mostrare da subito i loro vantaggi più sostanziali: in particolar modo la gestione multithread dei processi è un procedimento che richiederà del tempo per essere elaborato, sviluppato e portato a termine per garantire un risultato efficace. Con l'occasione, magari per recuperare un po' di tempo perduto (il consumo della memoria che cresce esponenzialmente è comunque un problema comune nel settore), Mozilla sta anche valutando la possibilità di sviluppare un modello DOM multithread: un modello che potrebbe richiedere compromessi al limite anche controproducenti, e tutti ancora da valutare nella realtà.

Auspicabilmente, procedendo per passi successivi e rispettando la nuova tabella da 6 settimane per lo sviluppo, presto o tardi tutte queste riflessioni potrebbero portare i propri frutti nelle versioni stabili di Firefox. Tempi precisi non sono ancora stati stabiliti, ma il fatto che Mozilla trovi il tempo per raccontare tutto questo lascia intendere che si sia fuori dalla fase teorica e si stia passando scrivere codice per mettere tutte queste idee alla prova. Nel frattempo l'attività ferve anche nel campo 64bit, per far sì che le versioni compilate in questo modalità non risentano di annosi problemi legati a compatibilità con i plugin, consumo di memoria e così via: passare a 64bit porterebbe in dote anche tanti vantaggi, sul piano sicurezza e non solo.

Luca Annunziata
22 Commenti alla Notizia Mozilla: più processi per Firefox
Ordina
  • da
    http://it.wikipedia.org/wiki/Mozilla_Firefox

    "
    La parola firefox significa letteralmente volpe di fuoco, ma in inglese indica il panda rosso. Secondo Jon Hicks, autore del logo di Mozilla Firefox, il panda rosso non evocava però la giusta immagine, quindi si ispirò ad una pittura giapponese raffigurante una volpe[4] ed il design finale del logo rappresenta effettivamente una volpe con la coda infuocata.
    "
    non+autenticato
  • - Scritto da: pippo
    > da
    > http://it.wikipedia.org/wiki/Mozilla_Firefox
    >
    > "
    > La parola firefox significa letteralmente volpe
    > di fuoco, ma in inglese indica il panda rosso.
    > Secondo Jon Hicks, autore del logo di Mozilla
    > Firefox, il panda rosso non evocava però la
    > giusta immagine, quindi si ispirò ad una pittura
    > giapponese raffigurante una volpe[4] ed il design
    > finale del logo rappresenta effettivamente una
    > volpe con la coda
    > infuocata.
    > "

    Grazie.
    Ci mancava!
  • Eh gia', perche' wikipedia adesso e' un sito affidabile e da citare. Ma va la'...
    non+autenticato
  • - Scritto da: fire fault
    > Eh gia', perche' wikipedia adesso e' un sito
    > affidabile e da citare. Ma va
    > la'...

    No, il panda rosso esiste veramente, l'ho visto personalmente allo zoo!
    Funz
    13021
  • - Scritto da: pippo
    > da
    > http://it.wikipedia.org/wiki/Mozilla_Firefox
    >
    > "
    > La parola firefox significa letteralmente volpe
    > di fuoco, ma in inglese indica il panda rosso.
    > Secondo Jon Hicks, autore del logo di Mozilla
    > Firefox, il panda rosso non evocava però la
    > giusta immagine, quindi si ispirò ad una pittura
    > giapponese raffigurante una volpe[4] ed il design
    > finale del logo rappresenta effettivamente una
    > volpe con la coda
    > infuocata.
    > "

    BALLE! PRENDI UN DIZIONARIO!

    Ci vuole tanto a capire che firefox vuol dire volpe di fuoco?????
    fire = fuoco
    fox = volpe

    Difficile eh?
    non+autenticato
  • panda rosso?
    non+autenticato
  • - Scritto da: stefano
    > panda rosso?

    Sì sì vabbè... Trollata troppo vecchia per avere seguito...
    non+autenticato
  • Infatti mi pare troppo strano che ancora al giorno d'oggi non si sappia che cosa sia un panda rossoA bocca aperta
    non+autenticato
  • - Scritto da: Cesare
    > Infatti mi pare troppo strano che ancora al
    > giorno d'oggi non si sappia che cosa sia un panda
    > rosso
    >A bocca aperta

    ma ci vuole tanto a capire che firefox vuol dire volpe di fuoco?????
    fire = fuoco
    fox = volpe

    Difficile eh?
    non+autenticato
  • - Scritto da: stefano
    > panda rosso?

    Ma il panda rosso non esiste, sono bianchi e neri... panda rosso ROTFL... ahahaha... che ignoranza... Rotola dal ridereRotola dal ridereRotola dal ridere























    Troll
    non+autenticato
  • OTTIMO GRAZIE MOZILLA, SONOS TATO FEDELISSIMO IN QUESTI 2 ANNI NONOSTANTE LA GRANDE ASCESA DI GOOGLE CHROME! FAGLIV EDERE CHI è IL BROWSER MIGLIORE!!!!!!!!!!!!!!!!!!!!!!1
    non+autenticato
  • - Scritto da: giuseppe
    > OTTIMO GRAZIE MOZILLA, SONOS TATO FEDELISSIMO IN
    > QUESTI 2 ANNI NONOSTANTE LA GRANDE ASCESA DI
    > GOOGLE CHROME! FAGLIV EDERE CHI è IL BROWSER
    > MIGLIORE!!!!!!!!!!!!!!!!!!!!!!1

    boh, tra netscape opera IE firefox chrome ed altri per linux ho sempre cercato di scegliere il migliore (evitando come la peste safari) senza stare a pensare alla fedeltà al browser, tutti i browser hanno pregi e difetti ed alcuni eccellono in uno scopo specifico (tranne safari che fa pena in tutto)per cui è difficile dire quale è il migliore (ma è facile che il peggiore sia safari)
    non+autenticato
  • A parte IE....

    Comunque Safari è orrendo solo su windows, su OSX non è messo male...anzi.
    Sgabbio
    26177
  • - Scritto da: giuseppe
    > OTTIMO GRAZIE MOZILLA, SONOS TATO FEDELISSIMO IN
    > QUESTI 2 ANNI NONOSTANTE LA GRANDE ASCESA DI
    > GOOGLE CHROME! FAGLIV EDERE CHI è IL BROWSER
    > MIGLIORE!!!!!!!!!!!!!!!!!!!!!!1

    Ottimo sì, almeno si spera che questo migliori la situazione dei continui freeze del "browser migliore del mondo". Qualche esempio?
    Prova a trascinare un allegato di posta da Windows Mail al desktop PASSANDO SU UNA FINESTRA DI FIREFOX. Risultato? Si blocca sia il client di posta che FF.
    Altro esempio? Crea una pagina HTML contenente questo script:

    <script> window.onresize = function() {alert('hello')} </script>

    e prova a ridimensionarla. Risultato? Il "browser migliore del mondo" si blocca (questo baco è in giro da almeno 7 mesi).

    Sono solo degli sbruffoni. Spero solo con il multiprocesso di risparmiare qualche bestemmia...
    non+autenticato
  • "Lo sviluppo del browser si avvia verso il multithreading più spinto..."

    "Innanzi tutto, i benefici di questo approccio multithreading..."

    "In particolar modo la gestione multithread dei processi è..."

    Vorrei farvi notare che avete un attimo travisato il concetto di multithreading o, per lo meno, avete travisato le parti che contengono la parolina "thread" nell'articolo.

    Benché sia stato specificato
    "Senza contare che, tenendo separati i processi di ciascuna scheda, finestra e plugin..."

    mi sembra di capire dall'articolo che il concetto di multithread o multiprocess sono, per l'autore, molto simili se non uguali.

    Benché, magari, in linea molto generale è così (si parla di eseguire operazioni contemporaneamente) i due argomenti sono decisamente diversi.

    Nell'articolo citato si fa riferimento, esclusivamente, al fatto che la garbage collection blocchi, ad esempio, il thread della ui o si parla relativamente al fatto che le operazioni di rete, di decodifica delle immagini e cosi via sono fatti su thread separati ma non si fa riferimento all'argomento multithreading per spiegare l'evoluzione futura di firefox perché non c'entra nulla
    non+autenticato
  • sei nuovo vero? tutti all'inizio attraversano questa faseSorride
  • - Scritto da: benkj
    > sei nuovo vero? tutti all'inizio attraversano
    > questa fase
    >Sorride

    No, seguo pi da una vita, a dire la verità, e so bene che il 99.99% dei commenti sono trollagini di vario livello e che gli articoli, spesso, sono copiati/tradotti male ... ma ogni tanto è bello tentare di fare qualcosa di costruttivo!

    Come dire, la speranza è l'ultima a morireSorride
    non+autenticato
  • come cacchio fa quel tipo a dire che con più thread si spreca meno memoria?

    la generazione di un thread richiede 2 MB fritti fritti solo per stoccare le informazioni di runtime del thread e lo stack
    non+autenticato
  • - Scritto da: collione
    >
    > la generazione di un thread richiede 2 MB fritti
    > fritti solo per stoccare le informazioni di
    > runtime del thread e lo
    > stack

    fammi capire
    leggi l'articolo, ti metti a pensare a quanto occupi un thread, magari facendo prove o non so che calcoli arrivi a comunicarci la stma di 2 mega dimostrando anche di aver studiato come funziona un sistema operativo

    e non ti è venuto in mente che
    > con più
    > thread si spreca meno
    > memoria?

    rispetto alla gestione multi processo!!!!!!!!!!!

    ma non era ovvio?

    che poi ora su chrome 3 schede aperte, magari anche qualche estensione di troppo (adblock gesture se apro il task manager ho 20 voci che vanno da 4 a 236 mega

    sai che cambierebbe con 2 mega in piu a testa?
    non+autenticato
  • - Scritto da: hp sucks
    > - Scritto da: collione
    > >
    > > la generazione di un thread richiede 2 MB
    > fritti
    > > fritti solo per stoccare le informazioni di
    > > runtime del thread e lo
    > > stack
    >
    > fammi capire
    > leggi l'articolo, ti metti a pensare a quanto
    > occupi un thread, magari facendo prove o non so
    > che calcoli arrivi a comunicarci la stma di 2
    > mega dimostrando anche di aver studiato come
    > funziona un sistema operativo

    1. Solitamente lo stack è di 8 mega, non due.
    2. La dimensione dello stack di un thread si può scegliere arbitrariamente prima di creare il thread.
    non+autenticato
  • - Scritto da: Nome e cognome
    >
    > 1. Solitamente lo stack è di 8 mega, non due.
    > 2. La dimensione dello stack di un thread si può
    > scegliere arbitrariamente prima di creare il
    > thread.

    Ma che razza di discorsi da bar sono???
    Che senso ha parlare di stack size senza nemmeno definire *prima* di quale compilatore stiamo parlando e su quale OS?

    Ad esempio il compilatore C di ms definisce una stack size pari ad 1 MB (di default)! gcc su linux credo 8 MB.
    non+autenticato