Mozilla: più processi per Firefox

È 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