Studio degli Android Runtime Environments ART e Dalvik

Transcript

1 Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Sistemi Operativi Studio degli Android Runtime Environments ART e Dalvik Anno Accademico 2014/2015 Candidato: Pierluigi De Gregorio matr. N46/1365

2 Dedico questo elaborato ai miei genitori, mia forza economica e morale, e alla mia ragazza che mi ha sempre sostenuto e ha sempre creduto in me. Grazie a loro ho sempre trovato la forza di rialzarmi ad ogni caduta e combattere ogni ostacolo.

3 Indice Introduzione iv 1 Dalvik Virtual Machine Un architettura basata su registri File.DEX Layout del file.dex File ODEX Differenze con la JVM Compilatore JIT Zygote Garbage Collector Android Runtime (ART) Miglioramenti apportati DEX2OAT Struttura del file.elf Compilazione Ahead-Of-Time (AOT) Garbage Collector Conclusioni 25 Bibliografia 26 ii

4 Elenco delle figure 1 Architettura Android OS v 1.1 Confronto tra JVM e DVM Struttura di un file.jar(sinistra) e di un file.dex(destra) Snellimento del file.jar Processo Zygote Confronto tra la conversione in Android Dalvik e ART file.elf Processo di compilazione in ART iii

5 Introduzione Il 5 novembre 2007 si affacciò per la prima volta sul mondo dei dispositivi mobile Android OS, il sistema operativo più utilizzato, ad oggi, dalle aziende produttrici di smartphone e smartwatch. Basato su kernel Linux, Android OS è un sistema operativo Open Source che utilizza software basati su diverse licenze, tra le quali la Licenza Apache grazie alla quale Google, azienda proprietaria di questo OS, può rilasciare liberamente distribuzioni e modifiche del codice sorgente[1]. A tal proposito, infatti, Google ha dato vita al cosiddetto Android Open Source Project (AOSP), che ha lo scopo principale di migliorare l esperienza mobile per gli utenti e garantire che i dispositivi mobili siano più consapevoli della posizione e delle preferenze del loro proprietario [2]. In questo modo il colosso di Mountain View è riuscito ad ottenere due grandi risultati: da un lato ha dato vita ad una grande comunità di sviluppatori che ogni giorno supportano e danno vita ad applicazioni che migliorano sensibilmente le funzionalità dei dispositivi, dall altro si è assicurata una vasta compatibilità di dispositivi mobile mettendo a disposizione tool di sviluppo e librerie (sempre Open Source) quali Android Software Developer Kit (SDK) e Native Development Kit (NDK). Come è stato accennato in precedenza, Android OS è stato creato per essere leggero e in grado di supportare dispositivi con hardware differenti. Ma come è strutturato questo sistema operativo? Se guardiamo Android da un punto di vista architetturale, possiamo notare come esso si sviluppa su un architettura a layer (i livelli inferiori offrono servizi ai livelli superiori). In particolare distinguiamo 4 livelli principali: Linux Kernel: è il layer più basso e fornisce, attraverso vari driver affidabili, una virtualizzazione dell hardware. Il motivo della scelta del kernel di Linux iv

6 Introduzione Figura 1: Architettura Android OS deriva dall esigenza di creare un OS in grado di fornire un livello elevato di sicurezza, una buona gestione della memoria nonché una elevata affidabilità. In questo modo, infatti, il vendor che intende dotare i propri dispositivi di Android non dovrà fare altro che installare il Linux Kernel ed implementare gli opportuni driver compatibili con il proprio hardware; Librerie native: contiene le librerie native (scritte in C/C++) tra le quali citiamo Surface Manager (si occupa di gestire l interfaccia grafica e le varie finestre presenti sullo schermo), OpenGL ES (gestisce elementi grafici), SGL(libreria che gestisce prettamente la grafica 2D), Secure Sockel Layer(si occupa della comunicazione sicura su socket). Queste librerie garantiscono, quindi, l interazione tra l utente e il dispositivo attraverso la grafica 2D e 3D, l utilizzo del touch screen e tutto quello che riguarda la multimedialità; Application Framework(AF): le librerie citate nel punto precedente vengono utilizzate da questo livello: in particolare le AF sono un insieme di API che vengono utilizzate per l esecuzione di specifiche funzionalità che sono fondamenv

7 Introduzione tali per un applicazione Android e quindi rappresentano l impalcatura di una qualsiasi applicazione; Android Runtime(AR): è il vero e proprio motore di Android OS. E costituito dalle cosiddette core libraries e dalla Dalvik Virtual Machine, sostituita da ART nell ultima release di Android.[3] In questo elaborato verrà approfondito proprio il livello Android Runtime e in particolare si parlerà della Dalvik Virtual Machine (DVM) e di ART, il nuovo runtime system implementato da Google che ha inizialmente affiancato Dalvik in Android 4.0 KitKat, per poi essere utilizzato definitivamente in Android 5.0 Lollipop. vi

8 Capitolo 1 Dalvik Virtual Machine La necessità di garantire un avvio e un tempo di risposta rapido da parte delle applicazioni che girano su hardware con risorse limitate, ha spinto Google a progettare un software in grado di sfruttare al massimo le risorse disponibili: nasce così la Dalvik Virtual Machine. La DVM è una macchina virtuale progettata da Dan Bornstein, dipendente di Google, e prende il nome dall omonimo villaggio di pescatori di cui la famiglia di Bornstein è originaria. Progettata e ottimizzata, infatti, proprio per sfruttare la poca memoria disponibile sui dispositivi mobile, permette a più istanze della macchina virtuale di girare contemporaneamente celando la gestione dei thread e della memoria al sistema operativo[4]: in questo modo si è in grado di semplificare il riutilizzo del codice e di eliminare o quanto meno prevenire problemi di incompatibilità.[5] 1.1 Un architettura basata su registri Solitamente chi progettava macchine virtuali preferiva utilizzare un architettura stack-based, impilando tutte le istruzioni all interno di uno stack. In questo modo, infatti, si andava incontro ad una notevole semplicità di implementazione sia della VM sia dei compilatori back-end (la maggior parte delle macchine virtuali venivano progettate per supportare un unico linguaggio di programmazione). Recenti studi, però, hanno dimostrato che cercare di semplificare le cose ha avuto un costo in termini di perfomance: confrontando, infatti, l architettura stack-based con quella register based 1

9 Capitolo 1. Dalvik Virtual Machine (architettura orientata sull uso dei registri), è risultato che la seconda richiede in media il 47% in meno di istruzioni VM rispetto alla prima ed impiega il 32.3% in meno di tempo per eseguire benchmark standard. Per comprendere meglio la differenza tra le due architetture possiamo fare un esempio molto semplice ma significativo. Consideriamo la seguente espressione[6]: b=c+d Una macchina stack-based traduce questa operazione nel seguente codice JVM(Java Virtual Machine) ILOAD d, ILOAD c, IADD, ISTORE b; In una VM register-based, invece, la stessa espressione si traduce nel seguente codice: IADD a,b,c; E facile notare come il codice utilizzato da un architettura register-based è notevolmente ridotto rispetto a quello utilizzato da una VM stack-based anche se, in media, come è stato dimostrato, comporta per una macchina reale l 1.07% di lavoro in più per ogni istruzione a causa di una maggiore lunghezza di queste ultime; il numero di istruzioni da elaborare, dunque, spiega perchè la prima risulta essere nettamente più veloce rispetto alla seconda. Tutto quello che è stato detto fino ad ora spiega il motivo per il quale Google abbia deciso di basare la Dalvik Virtual Machine su un architettura registered-based: capacità di elaborazione e limiti di memoria, infatti, sono vincoli decisamente rispettati dalla DVM.[7] 2

10 Capitolo 1. Dalvik Virtual Machine Figura 1.1: Confronto tra JVM e DVM 1.2 File.DEX A causa della molteplicità di applicazioni mobile scritte in linguaggio Java e compatibili con la Java Virtual Machine (JVM), è stato necessario creare un sistema di conversione in grado di garantire la compatibilità e la portabilità delle applicazioni stesse in Android OS. Poiché la JVM si basa su un architettura stack-based, infatti, è nata la necessità di convertire i file Java compatibili con la JVM in file.dex (Dalvik EXecutable) o.odex (Optimized Dalvik EXecutable) compatibili con la DVM (discendente, peraltro, direttamente dalla JVM), in modo tale da ottimizzare le risorse e soprattutto la memoria (Fig 1.1). Attraverso un tool integrato chiamato dx è possibile, quindi, trasformare il bytecode Java in un nuovo bytecode compatibile con la DVM e convertire i file.class in file.dex. Durante questo processo di conversione, in particolare, si verifica uno snellimento e una vera e propria compressione dei file.dex: in questo modo, infatti, si garantisce il rispetto del vincolo sui limiti di memoria, riducendo drasticamente l eccessivo spazio che generalmente viene dedicato ai comuni file Java in formato.jar. Più precisamente, questo risultato è stato ottenuto grazie ad un principio di condivisione che provoca una riorganizzazione del file.jar. Quest ultimo, infatti, è costituito da una serie di file.class (Fig. 1.2), uno per ogni classe, in cui è suddiviso il codice; la ridondanza del codice sta proprio nella mancanza di una struttu- 3

11 Capitolo 1. Dalvik Virtual Machine ra unitaria, la quale comporta una ripetizione degli oggetti che altrimenti potrebbero essere condivisi in maniera più intelligente ed efficiente in modo da evitare spreco di risorse e memoria. Invocando, quindi, il compilatore attraverso il tool dx, si crea il file.dex che sostituisce completamente la strutta divisa in classi descritta in precedenza con una ordinata solo ed esclusivamente per tipologia di codice.[8] Figura 1.2: Struttura di un file.jar(sinistra) e di un file.dex(destra) Per comprendere meglio quello che è stato detto in precedenza, consideriamo l esempio presentato al Google I/O nel 2008 dall ideatore della DVM Dan Bornstein: p u b l i c i n t e r f a c e Zapper { p u b l i c S t r i n g zap ( S t r i n g s, Object o ) ; } p u b l i c c l a s s Blort implements Zapper { p u b l i c S t r i n g zap ( S t r i n g s, Object o ) ;..... ; } p u b l i c c l a s s ZapUser{ 4

12 Capitolo 1. Dalvik Virtual Machine p u b l i c void usezap ( Zapper z ){ z. zap (..... ) } } Dalla figura 1.4 possiamo notare come in ogni classe del file.jar sono presenti ripetizioni delle costanti Ljava/lang/String nei metodi Ljava/lang/String; e Ljava/- lang/object che causano un eccessivo spreco di memoria. In un file.dex, invece, Ljava/lang/String è memorizzata una sola volta poiché si permette alle classi di condividere la Constant Pool (tabella dei simboli per la rappresentazione del class file per ogni classe ed interfaccia) riducendo al minimo l utilizzo delle costanti. Questa ripetizione minima, però, comporta l utilizzo di numerosi puntatori logici e/o riferimenti. Figura 1.3: Snellimento del file.jar 1.3 Layout del file.dex Un file.dex può essere visto da un punto di vista architetturale come una struttura basata su ben 8 campi, chiamata Big Header a causa dell elevato numero di informazioni in esso contenute: header: contiene l header del file.dex; string ids: si tratta di una lista che contiene gli identificatori di stringhe. Questi identificatori vengono utilizzati dal file.dex sia per la denominazione interna 5

13 Capitolo 1. Dalvik Virtual Machine (ad esempio descrittori) sia per le costanti. La lista deve, inoltre, essere ordinata sulla base del contenuto e non deve contenere identificatori duplicati; type ids: simile al campo precedente, questa volta si tratta di una lista contenente gli identificatori di tutti i tipi di dato(array, classi, tipi primitivi,ecc). Anche in questo caso, la lista deve essere ordinata sulla base degli identificatori del campo string id e non deve contenere voci duplicate; proto ids: lista contenente gli identificatori per tutti i prototipi delle funzioni presenti nel file.dex. L elenco contenuto in questo campo deve essere rigorosamente ordinato sulla base del tipo di ritorno con maggiore importanza(indice type ids). L elenco non deve contenere voci duplicate; field ids: lista contenente gli identificatori di tutti i campi a cui fa riferimento il file.dex. La lista deve essere ordinata in modo tale da specificare prima il tipo del campo e poi il nome; method ids: è una lista contenente tutti i metodi a cui fa riferimento il file.dex e deve essere ordinato nel seguente modo: prima va indicato il tipo del metodo, poi il nome ed infine il prototipo; class defs: lista contenente le definizioni delle classi. In particolare, essa deve essere ordinata in modo tale che la superclasse di una determinata classe e i suoi metodi vengono visualizzati prima della classe di riferimento; data: l area dati contiene tutte quelle informazioni di supporto per le liste descritte nei precedenti punti. E importante sottolineare che a questo livello di categoria i vari oggetti hanno esigenze differenti di allineamento: per questo motivo vengono talvolta utilizzati dei byte di riempimento in modo tale da garantire un corretto allineamento. 6

14 Capitolo 1. Dalvik Virtual Machine 1.4 File ODEX Le applicazioni che vengono installate in Android OS sono disponibili in pacchetti aventi estensione.apk. In particolare, questi pacchetti contengono alcuni file con estensione.odex (Optimized Odex) la cui funzione principale è quella di risparmiare spazio. Più precisamente, un file con questa estensione, chiamato anche odexed file, rappresenta quella parte ottimizzata di un applicazione che permette di eseguire velocemente il boot della stessa. Tutto ciò è possibile grazie al caricamento dell applicazione all interno della cosiddetta Dalvik Cache, uno spazio temporaneo che viene utilizzato dalla DVM contenente indirizzi di memoria, struttura delle directory delle app installate e dati vari. Grazie alla creazione dei file.odex, infine, il sistema operativo è in grado di conoscere in anticipo quali applicazioni avviare (le informazioni sono presenti proprio nella Dalvik Cache) in modo da ridurre il tempo di avvio del sistema operativo. Un file ODEX viene creato grazie ad un software chiamato dex2opt. Nella fase di ottimizzazione vengono effettuate una serie di operazioni di snellimento del file.dex: i metodi virtuali, infatti, vengono sostituiti con opportune versioni ottimizzate contenenti l indice della tabella virtuale del metodo chiamato, in modo da evitare la ricerca nella Virtual Table in fase di esecuzione; vengono potati, inoltre, i metodi vuoti, ossia quei metodi come Object init che vengono utilizzati in fase di allocazione di un oggetto, ecc. Durante la fase di ottimizzazione del file.dex, infine, il software dex2opt ricorre spesso all indicizzazione poiché permette di ignorare la risoluzione simbolica iniziale e una rapida esecuzione.[9] 1.5 Differenze con la JVM Come è stato già discusso in precedenza, la DVM è nata in seguito all esigenza di utilizzare una VM in grado di girare su ambienti a memoria ridotta, sfruttando le caratteristiche del sistema. Ma se è vero che si preferisce non sfruttare la VM Java, perché non si è utilizzato almeno il suo byte-code, implementando solo i metodi che servono per la sua interpretazione? Nei paragrafi precedenti, è stato mostrato come il 7

15 Capitolo 1. Dalvik Virtual Machine codice di un applicazione Java sia molto ridondante e che un file.dex elimina questi problemi: ad esempio, se un file Java racchiude codice per un totale di 100 Kb, lo stesso potrà essere realizzato in formato.dex pesando circa la metà! Ciò che è stato appena detto, però non è l unica caratteristica che differenzia la JVM con la DVM. Per quanto riguarda l Istruction Set, infatti, Dalvik presenta 218 tipologie di opcodes contro i 200 di Java. Per sottolineare ulteriormente la differenza anche a basso livello tra le due macchine virtuali, basti pensare, ad esempio, che Java utilizza una dozzina di opcodes, totalmente assenti in Dalvik, che vengono utilizzati per il trasferimento di dati dallo stack alla lista contenente le variabili locali; inoltre, mentre il bytecode della JVM utilizza più opcodes per effettuare confronti tra oggetti, Dalvik ne utilizza uno solo semplificando ulteriormente le cose. Infine, la JVM dedica opcodes diversi a seconda del tipo di dato mentre la DVM ne mette a disposizione uno uguale per tutti i tipi. Le istruzioni in linguaggio macchina in Dalvik, infine, sono molto più lunghe poichè, trattandosi di un architettura register-based, contengono sia gli indirizzi di origine che di destinazione dei registri.[10] 1.6 Compilatore JIT A partire dalla versione Android 2.2 Froyo, è stato adottato un compilatore JIT (Just In Time) che interpreta le applicazione nel momento in cui vengono eseguite: con Dalvik, quindi, Android diventa un sistema operativo a compilazione dinamica, in cui il compilatore viene utilizzato anche in fase di esecuzione. Nelle versioni immediatamente precedenti Android 2.2 Froyo, però, Google decise di non adottare un siffatto compilatore: se è vero che la DVM interpreta una sola istruzione alla volta del bytecode, è anche vero che non tutte le istruzioni devono essere tradotte ogni volta che le applicazioni vengono eseguite perché vari elementi, librerie in primis, sono già scritte in linguaggio macchina e quindi il compilatore non deve agire. Alcuni studi, infatti, hanno dimostrato proprio che solo una piccola parte del tempo impiegato per l esecuzione di un applicazione viene utilizzato per l interpretazione del bytecode. A tutto quanto detto fino ad ora va aggiunto, inoltre, l utilizzo di un bytecode compatto 8

16 Capitolo 1. Dalvik Virtual Machine e ottimizzato per dispositivi con limiti di risorse e di memoria. Purtroppo, però, la scelta iniziale del colosso di Mountin View si è rivelata infelice in quanto si è andati incontro a seri e fastidiosi rallentamenti in fase di esecuzione. Ma come opera un compilatore JIT? Spesso capita che l interprete (programma che esegue altri programmi convertendo il codice sorgente il linguaggio macchina) si trovi dinanzi a porzioni di codice intrecciate e abbastanza complicate da un punto di vista computazionale. Il compilatore JIT interviene proprio in queste situazioni, affiancando l interprete nella traduzione del codice sorgente in linguaggio macchina e ottimizzandolo. Questa operazione di semplificazione si rileva molto efficace perché ogni qual volta si va ad eseguire successivamente queste porzioni di codice, esse si troveranno già tradotte in linguaggio macchina: le prestazioni migliorano notevolmente. Ciò che contraddistingue un buon compilatore JIT, però, è la capacità di capire quando e dove intervenire: quello utilizzato da Android Dalvik, infatti, garantisce un minor utilizzo della memoria e un miglioramento delle prestazioni eliminando quella fastidiosa attesa che si riscontrava nelle prime versioni di Android ogni qual volta si lanciava un applicazione.[11] Al giorno d oggi sono molto utilizzati due tipi di compilatori JIT: Method based: utilizzato da Java, questo compilatore compila in codice nativo e ottimizza i metodi che sono più complessi da un punto di vista computazionale. Poiché viene compilato il metodo per intero, spesso traduce anche porzioni di codice che vengono utilizzate raramente sprecando tempo inutilmente. Traced based: questo tipo di compilatore, individua solo istruzioni (e non metodi come nel caso precedente) computazionalmente complesse e le raggruppa in tracce; una volta compilate, queste tracce vengono tutte racchiuse in una translation cache: in questo modo, l esecuzione avviene per tracce successive. 9

17 Capitolo 1. Dalvik Virtual Machine Figura 1.4: Processo Zygote 1.7 Zygote Tra le varie caratteristiche di Android, assume un ruolo importante in termini di performance la riduzione dell overhead durante la fase di avvio di un applicazione in modo da garantire una risposta rapida da parte del dispositivo. La DVM è una macchina virtuale di tipo process: questi tipi di VM sono in grado di eseguire un unico processo alla volta; di conseguenza, per poter eseguire contemporaneamente più applicazioni, devono essere create più istanze di Dalvik Virtual Machine, una per ogni applicazione eseguita. L overhead, quindi, viene ridotto proprio andando a velocizzare il processo di creazione delle varie istanze attraverso il cosiddetto Zygote, un processo daemon (eseguito in background) inizializzato dal sistema operativo la cui funzione è quella di avviare applicazioni. Il suo avvio è innescato da init.rc dopo Service Manager, ma in realtà è iniziato da app process. Consideriamo, a tal proposito, la sequenza di istruzioni necessarie per avviare un processo di questo tipo: s e r v i c e zygote / system / bin / app process Xzygote / system / bin zygote s t a r t system s e r v e r c l a s s main s o c k e t zygote stream 660 root system 10

18 Capitolo 1. Dalvik Virtual Machine o n r e s t a r t w r i t e / sys / android power / r e q u e s t s t a t e wake o n r e s t a r t w r i t e / sys /power/ s t a t e on o n r e s t a r t r e s t a r t media o n r e s t a r t r e s t a r t netd Notiamo come il processo Zygote viene avviato come system service e come l app process sia effettivamente l istruzione che lo avvia: più precisamente, quest ultima crea la prima istanza di DVM ed effettua una chiamata al metodo main() di Zygote. Una volta che esso è stato avviato, quindi, non solo vengono caricate tutte le risorse e le classi Java necessaria ma viene avviato anche il System Server, il quale apre una socket /dev/socket/zigote in modo tale da mettersi in ascolto per eventuali richieste di avvio da parte delle varie applicazioni. Quali sono, quindi, le operazioni che vengono fatte dal processo Zygote per avviare le applicazioni? Quando viene ricevuta una richiesta di avvio tramite la suddetta socket, lo Zygote effettua una fork() dando vita ad una nuova istanza di DVM precaricata con tutte quelle risorse e quelle classi che sono necessarie ad ogni applicazione (Fig. 1.4). Poiché Android utilizza un kernel Linux, viene implementata una stategia chiamata Copy On Write (COW): quando lo Zygote effettua una fork, non viene effettuata nessuna copia della memoria in un altro spazio, ma viene condivisa e marcata come copy-on-write, ovvero quando un processo di un applicazione cerca di accedere e modificare quell area di memoria, il kernel intercetta la chiamata e ne crea una copia che potrà essere opportunamente modificate. In altre parole, si ritiene non necessario creare una copia della memoria ogni qual volta viene effettuata una fork(), ma solo nel momento in cui un processo richiede di poter modificare le informazioni in essa contenute.[12] 11

19 Capitolo 1. Dalvik Virtual Machine 1.8 Garbage Collector La garbage collection (letteralmente raccolta dei rifiuti) rappresenta un modo automatico di gestire la memoria grazie alla quale un compilatore o il sistema operativo è in grado di liberare quei blocchi di memoria che, precedentemente referenziati (ovvero allocate da un processo o utilizzate da un applicazione), non vengono più utilizzati e quindi possono essere utilizzate da altri processi; il Garbage Collector, quindi, annoterà queste aree e le libererà automaticamente. Grazie al Garbage Collector, il programmatore viene esonerato dal preoccuparsi del quantitativo di memoria da allocare per la sua applicazione e soprattutto di doverla successivamente deallocare. Purtroppo, però, come sarà descritto in seguito, un sistema automatico per la gestione della memoria non sempre si comporta bene. In Android Dalvik, il processo di gestione della memoria da parte del Garbage Collector viene dettata da due pause: la prima pausa avviene durante la fase di enumerazione in cui si contano i blocchi di memoria da liberare, mentre la seconda si verifica durante la fase di marcatura. Per pausa, in questo caso, si intende l arco di tempo in cui viene letteralmente sospesa l esecuzione del codice di un applicazione e di tutti i suoi thread. Se la pausa è troppo lunga, l applicazione rallenta eccessivamente la sua esecuzione a causa della perdita di numerose frame, rendendo pessima l user experience. Google sostiene che una durata media di queste pause si aggira intorno ai 54 ms per un LG Nexus 5, comportando la perdita di almeno 4 frames ogni volta che il Garbage Collector si attiva. In realtà, come dimostrato da Andrei Frumusanu, la durata di una pausa dipende soprattuto dal tipo di applicazione avviata. Consideriamo, a questo proposito, il seguente esempio riportato dallo stesso Andrei Fumusanu sul sito [13]: :56:14.275: D/dalvikvm(30615): GC FOR ALLOC freed 4442K, 25% free 20183K/26856K, paused 24ms, total24ms :56:16.785: I/dalvikvm-heap(30615): Grow heap (frag case) to MB for byte allocation :56:17.225: I/dalvikvm-heap(30615): Grow heap (frag case) to MB for byte allocation :56:17.625: I/Choreographer(30615): Skipped 35 frames! The application may be doing too much work on its main thread.ù :56:19.035: D/dalvikvm(30615): GC CONCURRENT freed 35838K, 43% free 51351K/89052K, paused 3ms+5ms, total 106ms :56:19.035: D/dalvikvm(30615): WAIT FOR CONCURRENT GC blocked 96ms :56:19.815: D/dalvikvm(30615): GC CONCURRENT freed 7078K, 42% free 52464K/89052K, paused 14ms+4ms, total 96ms 12

20 Capitolo 1. Dalvik Virtual Machine :56:19.815: D/dalvikvm(30615): WAIT FOR CONCURRENT GC blocked 74ms :56:20.035: I/Choreographer(30615): Skipped 141 frames! The application may be doing too much work on its main thread :56:20.275: D/dalvikvm(30615): GC FOR ALLOC freed 4774K, 45% free 49801K/89052K, paused 168ms, total 168ms :56:20.295: I/dalvikvm-heap(30615): Grow heap (frag case) to MB for byte allocation :56:21.315: D/dalvikvm(30615): GC FOR ALLOC freed 1359K, 42% free 55045K/93612K, paused 95ms, total 95ms :56:21.965: D/dalvikvm(30615): GC CONCURRENT freed 6376K, 40% free 56861K/93612K, paused 16ms+8ms, total 126ms :56:21.965: D/dalvikvm(30615): WAIT FOR CONCURRENT GC blocked 111ms :56:21.965: D/dalvikvm(30615): WAIT FOR CONCURRENT GC blocked 97ms :56:22.085: I/Choreographer(30615): Skipped 38 frames! The application may be doing too much work on its main thread :56:22.195: D/dalvikvm(30615): GC FOR ALLOC freed 1539K, 40% free 56833K/93612K, paused 87ms, total 87ms :56:22.195: I/dalvikvm-heap(30615): Grow heap (frag case) to MB for byte allocation :56:22.475: D/dalvikvm(30615): GC FOR ALLOC freed 308K, 39% free 59497K/96216K, paused 84ms, total 84ms :56:22.815: D/dalvikvm(30615): GC FOR ALLOC freed 287K, 38% free 60878K/97516K, paused 95ms, total 95ms Si tratta di un estratto del registro di un applicazione dopo i primi secondi dal suo avvio. Possiamo notare come il Garbage Collector venga richiamato per 9 volte causando il blocco dell applicazione per un totale di 603 ms e una perdita di ben 214 frame. La maggior parte delle pause sono dovute alle varie richieste di allocazione da parte della memoria, come indicato dal tag GC FOR ALLOC. Il funzionamento del Garbage Collector utilizzato da Android Dalvik, infine, si basa sull approccio march and sweep. Secondo questo approccio, viene mantenuta una lista contenente tutti quei blocchi della memoria heap contrassegnati come liberi. Nel momento in cui un processo richiede l allocazione di un blocco libero e la lista risulta vuota, il Garbage Collector si comporta nel seguente modo: utilizza dei bit per marcare quegli oggetti che sono ancora in uso e che quindi non dovrebbero essere rimossi. Questi bit vengono memorizzati in un area separata all interno della memoria heap; riordina e raccoglie tutti i blocchi non marcati e li inserisce all interno della lista vuota. Più precisamente, il funzionamento dell algoritmo può essere riassunto nel seguente pseudo-codice: 13

21 Capitolo 1. Dalvik Virtual Machine f o r each root v a r i a b l e r mark ( r ) ; sweep ( ) ; Per poter distinguere gli oggetti in uso da quelli che possono essere eliminati, ognuno di essi contiene un campo booleano che indica lo stato marked(true) o unmarked(false). Generalmente tutti gli oggetti quando vengono creati risultano unmarked di default. Un generico oggetto p e tutti quelli che sono accessibili indirettamente attravero p vengono marcati attraverso un operazione ricorsiva: void mark ( Object p ){ i f (! p. marked ) p. marked = true ; f o r each Object q r e f e r e n c e d by p mark ( q ) ; Questo algoritmo ricorsivo non fa niente se incontra oggetti che risultano già marcati; di conseguenza termina nel momento in cui tutti gli oggetti accessibili risultano marked. Nella seconda fase l algoritmo mark and sweep scansiona tutti gli oggetti nella memoria heap in modo tale da localizzare tutti quelli che risultano unmarked. In particolare, la memoria allocata per gli oggetti non marcati viene recuperata durante la fase di scansione, mentre il campo booleano degli oggetti che sono stati segnati in precedenza come marked viene settato a false per la successva invocazione dell algoritmo. Le operazioni effettuate durante la fase di sweep sono riportate in seguito: void sweep ( ) f o r each Object p in the heap i f ( p. marked ) p. marked = f a l s e e l s e heap. r e l e a s e ( p ) ; [ 1 4 ] 14