Come funziona il nuovo meccanismo di conteggio automatico dei riferimenti?

Qualcuno può spiegarmi brevemente come funziona ARC? So che è diverso dalla Garbage Collection, ma mi chiedevo esattamente come funzionasse.

Inoltre, se ARC fa ciò che fa GC senza ostacolare le prestazioni, perché Java usa GC? Perché non usa anche ARC?

Ogni nuovo sviluppatore che arriva a Objective-C deve imparare le rigide regole su quando conservare, rilasciare e rilasciare automaticamente gli oggetti. Queste regole specificano anche le convenzioni di denominazione che implicano il conteggio degli oggetti restituiti dai metodi. La gestione della memoria in Objective-C diventa una seconda natura quando si prendono a cuore queste regole e le si applicano in modo coerente, ma anche gli sviluppatori Cocoa più esperti saltano di tanto in tanto.

Con Clang Static Analyzer, gli sviluppatori di LLVM hanno capito che queste regole erano abbastanza affidabili da poter costruire uno strumento per segnalare perdite di memoria e rilasci in eccesso all'interno dei percorsi che il tuo codice prende.

Il conteggio dei riferimenti automatici (ARC) è il passo logico successivo. Se il compilatore è in grado di riconoscere dove si dovrebbero conservare e rilasciare oggetti, perché non è necessario inserire quel codice? Compiti rigidi e ripetitivi sono ciò che i compilatori e i loro fratelli sono bravi a fare. Gli umani dimenticano le cose e commettono errori, ma i computer sono molto più coerenti.

Tuttavia, questo non ti libera completamente dal preoccuparti della gestione della memoria su queste piattaforme. Descrivo il problema principale a cui prestare attenzione (mantenere i cicli) nella mia risposta qui , che potrebbe richiedere un piccolo pensiero da parte vostra per contrassegnare i punti deboli. Tuttavia, questo è minore rispetto a quello che stai guadagnando in ARC.

Rispetto alla gestione manuale della memoria e alla garbage collection, ARC offre il meglio di entrambi i mondi eliminando la necessità di scrivere codice di conservazione / rilascio, senza avere i profili di memoria di arresto e dente di sega visti in un ambiente garbage collection. Gli unici vantaggi che la raccolta dei rifiuti ha su questo sono la sua capacità di gestire i cicli di mantenimento e il fatto che le assegnazioni di proprietà atomiche sono economiche (come discusso qui ). So che sto sostituendo tutto il mio codice GC GC esistente con implementazioni ARC.

Se questo possa essere esteso ad altre lingue, sembra orientato al sistema di conteggio dei riferimenti in Objective-C. Potrebbe essere difficile applicarlo a Java o ad altre lingue, ma non conosco abbastanza i dettagli del compilatore di basso livello per fare una dichiarazione definitiva lì. Dato che Apple è quella che sta spingendo questo sforzo in LLVM, Objective-C verrà prima a meno che un'altra parte non impegna risorse significative proprie a questo.

La presentazione di questi sviluppatori scioccati al WWDC, quindi le persone non erano consapevoli che si potesse fare qualcosa del genere. Potrebbe apparire su altre piattaforme nel tempo, ma per ora è esclusivo di LLVM e Objective-C.

ARC è solo il vecchio Mantieni / Rilascio (MRC) con il compilatore che capisce quando chiamare il blocco / rilascio. Tenderà ad avere prestazioni più elevate, un utilizzo di memoria di picco inferiore e prestazioni più prevedibili rispetto a un sistema GC.

D'altra parte alcuni tipi di strutture dati non sono possibili con ARC (o MRC), mentre GC può gestirli.

Ad esempio, se si dispone di una classe denominata nodo e il nodo ha un NSArray di figli e un singolo riferimento al suo genitore che "funziona" con GC. Con ARC (e anche il conteggio dei riferimenti manuali) hai un problema. Ogni nodo dato sarà referenziato dai suoi figli e anche dai suoi genitori.

Piace:

A -> [B1, B2, B3]
B1 -> A, B2 -> A, B3 -> A

Tutto va bene mentre stai usando A (ad esempio tramite una variabile locale).

Quando hai finito (e B1 / B2 / B3), un sistema GC alla fine deciderà di guardare tutto ciò che può trovare a partire dallo stack e dai registri della CPU. Non troverà mai A, B1, B2, B3, quindi li finalizzerà e riciclerà la memoria in altri oggetti.

Quando si utilizza ARC o MRC e si termina con A, si ha un refcount di 3 (B1, B2 e B3 fanno tutti riferimento a esso) e B1 / B2 / B3 avrà tutti un conteggio di riferimento di 1 (l'array NS di A contiene un riferimento a ogni). Quindi tutti quegli oggetti rimangono vivi anche se nulla può mai usarli.

La soluzione comune è decidere che uno di quei riferimenti deve essere debole (non contribuire al conteggio dei riferimenti). Ciò funzionerà per alcuni schemi di utilizzo, ad esempio se si fa riferimento a B1 / B2 / B3 solo tramite A. Tuttavia, in altri schemi fallisce. Ad esempio, se a volte tieni premuto B1 e ti aspetti di risalire tramite il puntatore genitore e trovare A. Con un riferimento debole se tieni premuto B1, A può (e normalmente) evaporare e prendere B2 e B3 con esso.

A volte questo non è un problema, ma alcuni modi molto utili e naturali di lavorare con strutture complesse di dati sono molto difficili da usare con ARC / MRC.

Quindi ARC affronta lo stesso tipo di problemi target GC. Tuttavia ARC funziona su un set più limitato di schemi di utilizzo rispetto a GC, quindi se prendessi un linguaggio GC (come Java) e innesti qualcosa come ARC su di esso alcuni programmi non funzionerebbero più (o almeno genererebbero tonnellate di memoria abbandonata e può causare seri problemi di scambio o esaurire la memoria o lo spazio di scambio).

Puoi anche dire che ARC attribuisce una priorità maggiore alle prestazioni (o forse alla prevedibilità) mentre GC attribuisce una priorità maggiore all'essere una soluzione generica. Di conseguenza, GC ha requisiti CPU / memoria meno prevedibili e prestazioni (normalmente) inferiori rispetto ad ARC, ma può gestire qualsiasi modello di utilizzo. ARC funzionerà molto meglio per molti modelli di utilizzo comuni, ma per alcuni (validi!) Modelli di utilizzo cadrà e morirà.

Magia

Ma più specificamente ARC funziona facendo esattamente quello che faresti con il tuo codice (con alcune differenze minori). ARC è una tecnologia di compilazione, a differenza di GC che è runtime e influirà negativamente sulle prestazioni. ARC monitorerà i riferimenti agli oggetti per te e sintetizzerà i metodi di mantenimento / rilascio / rilascio automatico secondo le normali regole. Per questo motivo ARC può anche rilasciare le cose non appena non sono più necessarie, piuttosto che gettarle in un pool di autorelease esclusivamente per motivi di convenzione.

Alcuni altri miglioramenti includono l'azzeramento di riferimenti deboli, la copia automatica dei blocchi nell'heap, le accelerazioni su tutta la linea (6 volte per i pool di rilascio automatico!).

Discussioni più dettagliate su come funziona tutto ciò si trovano nei documenti LLVM su ARC.

Varia notevolmente dalla raccolta dei rifiuti. Hai visto gli avvisi che indicano che potresti perdere oggetti su linee diverse? Queste dichiarazioni ti dicono persino su quale linea hai assegnato l'oggetto. Questo è stato fatto un passo avanti e ora è possibile inserire retain/ releaseistruzioni nelle posizioni corrette, meglio della maggior parte dei programmatori, quasi il 100% delle volte. Di tanto in tanto ci sono alcune strane istanze di oggetti conservati con cui è necessario aiutarlo.

Molto ben spiegato dalla documentazione per gli sviluppatori Apple. Leggi "Come funziona ARC"

Per assicurarsi che le istanze non scompaiano mentre sono ancora necessarie, ARC tiene traccia di quante proprietà, costanti e variabili si riferiscono attualmente a ciascuna istanza della classe. ARC non dislocerà un'istanza fintanto che esiste almeno un riferimento attivo a quell'istanza.

Per assicurarsi che le istanze non scompaiano mentre sono ancora necessarie, ARC tiene traccia di quante proprietà, costanti e variabili si riferiscono attualmente a ciascuna istanza della classe. ARC non dislocerà un'istanza fintanto che esiste almeno un riferimento attivo a quell'istanza.

Conoscere il diff. tra Garbage Collection e ARC: leggi questo

ARC è una funzione di compilazione che fornisce la gestione automatica della memoria degli oggetti.

Invece di dover ricordare quando utilizzare retain, releasee autoreleaseARC valuta i requisiti di durata dei tuoi oggetti e inserisce automaticamente le chiamate di gestione della memoria appropriate al momento della compilazione. Il compilatore genera anche metodi dealloc appropriati per te.

Il compilatore inserisce le retain/releasechiamate necessarie al momento della compilazione, ma tali chiamate vengono eseguite in fase di esecuzione, proprio come qualsiasi altro codice.

Il seguente diagramma ti darebbe una migliore comprensione di come funziona ARC.

Coloro che sono nuovi nello sviluppo di iOS e che non hanno esperienza lavorativa sull'obiettivo C. Fare riferimento alla documentazione di Apple per la Guida alla programmazione della gestione avanzata della memoria per una migliore comprensione della gestione della memoria.