Il browser di casa Microsoft, fino alla release 6 (almeno fino ad oggi non è stato scoperto nessun caso particolare sulle versioni 7 e 8), presentava un corposo bug che limitava le sue funzionalità quando gli oggetti istanziati nel browser raggiungevano un numero elevato. Questo perché il garbage collector di Internet Explorer non liberava la memoria per quegli oggetti (in particolare oggetti DOM e ActiveX) che non erano più referenziati in quanto non analizzava in maniera ottimale eventuali riferimenti circolari tra gli oggetti.
Perché parlarne in questo articolo sulle closure? Semplicemente perché utilizzando questa tecnica è possibile incappare in questo tipo di problematica in IE.
Sinteticamente, ogni qual volta un oggetto non viene più referenziato da nessun'altra entità presente nell'applicazione, la memoria occupata per quel particolare oggetto viene liberata appunto da un componente, il garbage collector. Quest'ultimo deve anche analizzare riferimenti incrociati e nel caso di oggetti isolati dal resto dell'applicazione deve liberare ulteriore memoria (se A è l'unico oggetto che fa riferimento a B, B l'unico a fare riferimento a C e C l'unico a fare riferimento ad A, tutti e tre gli oggetti possono essere eliminati). Il garbage collector di IE non controlla i riferimenti incrociati di tutti gli oggetti e non libera quindi tutta la memoria potenzialmente non utilizzata creando rallentamenti e ritardi. Un eventuale soluzione per risolvere situazioni in cui i riferimenti circolari sono l'unica strada da seguire è quella di utilizzare l'evento onunload per eliminare l'associazione tra evento e funzione callback tramite l'assegnazione di null.
Questa sul memory-leak è stata una semplice introduzione del problema che però può essere evitato con un minimo di attenzione e di buona programmazione.
Nel prossimo capitolo metteremo insieme le competenze acquisite in questo e nel precedente articolo per capire come utilizzare la programmazione Object-Oriented in JavaScript.
