2010-04-19 8 views
11

Attualmente sto ripensando alla gestione degli oggetti di smaltimento del framework JavaScript qooxdoo.
Dai un'occhiata alla seguente diagramma (A è attualmente in campo di applicazione):Quali algoritmi di garbage collection utilizzano tutti e 5 i principali browser?

diagram http://yuml.me/51747906.jpg

Diciamo che vogliamo eliminare B. In generale, abbiamo tagliato tutto il riferimento tra tutti gli oggetti. Ciò significa che abbiamo tagliato le connessioni da 1 a 5 nell'esempio. E 'davvero necessario?
Per quanto ho letto here, i browser utilizzare l'algoritmo mark-and-sweep. In tal caso, abbiamo solo bisogno di tagliare il riferimento 1 (connessione allo scope) e 5 (connessione al DOM) che potrebbe essere molto più veloce.
Ma posso essere sicuro che tutti i browser utilizzano l'algoritmo di mark-and-sweep o qualcosa di simile?

+0

Forse dovresti dirci quali sono i 5 principali browser _sono_ nella tua visualizzazione. Sono IE6, IE7, IE8, FF3 e Safari per esempio ?! –

+1

Con 5 browser principali intendo FF (2, 3, 3.5, 3.6), Opera (9, 10, 10.5), Safari (3, 4), Chrome (2, 3, 4, 5) e IE (6, 7 8). –

risposta

2

Per qualsiasi garbage collector discreto (non solo mark-and-sweep), taglio collegamento 1 sarebbe sufficiente per rilasciare B (e C e D e la finestra). L'allocazione basata sul conteggio dei riferimenti non riuscirebbe a rilasciare B e D a causa dei loro riferimenti ciclici (i riferimenti B dei riferimenti D e D B) ma il conteggio dei riferimenti non è in realtà una garbage collection.

penso che sia lecito ritenere che tutti i browser usano un garbage collector decente (o meglio, con i browser, niente è mai davvero sicuro, ma un'implementazione JavaScript non utilizza un adeguato garbage collector è improbabile comunque).

+1

Il conteggio dei riferimenti non è sufficiente per implementare la garbage collection, ma può comunque far parte di un GC decente. Quando il conteggio colpisce 0, sai positivamente che puoi raccogliere l'oggetto. Questa scorciatoia può permetterti di eseguire il GC su molti oggetti senza un costoso passaggio di mark-and-sweep. Inoltre, quando arriva il momento di fare un mark-and-sweep, c'è meno spazzatura da pulire. – MSalters

+0

Il conteggio dei riferimenti è costoso, a causa degli aggiornamenti dei conteggi (in particolare per quanto riguarda la cache). Asintoticamente, anche senza cicli, il mark-and-sweep è meno costoso del conteggio dei riferimenti. Il conteggio dei riferimenti, tuttavia, interagisce meglio con la memoria virtuale in alcune situazioni, ed è per questo che Perl lo usa (Perl crede nei collegamenti dinamici per nome piuttosto che per puntatori, e quindi crea pochissimi "veri cicli", tuttavia, Perl ha anche un e-sweep GC). –

2

Il fatto è che in un mondo ideale, è fondamentalmente solo bisogno di staccare nodi DOM e listener di eventi nativi. Il problema però è che il sistema originale in qooxdoo è stato progettato attorno a browser buggati come IE6. Abbiamo visto un utilizzo della memoria ridotto in modo massiccio quando cancelliamo il più possibile da soli. Nel mondo di oggi, tuttavia, lo ridisegnerei in modo che sia OK in IE6, ma non ottimizzato per i suoi problemi.

C'è anche una differenza di una chiusura completa di tutta l'applicazione (smaltire tutto) e solo per smaltire una singola frazione di un'applicazione. Nell'ultimo scenario è necessario agire con cautela per non disporre delle cose che sono ancora necessarie.