Heap Size

[Ikon]

dunque io uso VM heap size ed il massimo impostabile è 64mb e a default è 64mb. Ho provato 28mb senza notare alcunchè, Michelasso ha impostato 8 mb e ha avuto continui bootloop.
In rete ho trovato che il default di gingerbread è 24, di honeycomb è 48, il resto l'ho scritto sopra

I suoi bootloop sono dovuti al fatto che Zygote non riesce a caricarci tutta la roba allo startup...

[samurri]

... i processi partono e questi al posto di avere un loro heap usano tutte lo stesso heap comune.

questa non l'ho capita

[Ikon]

questa non l'ho capita

hai ragione! magari se rileggessi quello che scrivo prima di premere invia... aspetta vado a editare!

[Ikon]

Qui si capisce meglio la questione Zygote:

Zygote enables multiple Dalvik instances to share memory to limit the memory burden of each running concurrently. As the name implies, Zygote's purpose is to provide a preloaded Android process ready for a new application, without incurring the delay of starting from scratch. During the initialization of the Zygote, core classes are preloaded into memory to allow even faster application startup. Since each Zygote uses copy-on-write for shared memory space, much of the memory for each application is reused and thereby places a lighter burden on the limited resources of the device. This only works because these core classes are mostly read-only and will rarely require more than one version for all applications. Compared to a typical Java virtual machine, this is quite an improvement in performance and memory efficiency since they do not exhibit this type of memory sharing between instances. Once the classes are loaded, the Dalvik VM itself is then initialized and is ready to run Dalvik bytecode from a dex file. Once the Zygote has been inhabited by a new application, another Zygote is forked to wait on a socket for the next application to be launched.

(cit. Android Dalvik Virtual Machine)

Dove:

Every Android application runs in its own process, with its own instance of the Dalvik virtual machine.

(cit. http://developer.android.com/about/versions/index.html)

Abbiamo tutti gli elementi per valutare la questione "numero di istanze della VM", ci mancano elementi sulla frequenza del garbage collector. Se troviamo anche quelli possiamo tirare giù qualche formula!

[Ikon]

So garbage collection can be triggered when an allocation fails, when an OutOfMemoryError is about to be triggered, when the size of the heap hits some soft limit, and when a GC was explicitly requested. Each of these causes has its own specification indicating whether the GC is a partial GC (only free from active heap), a concurrent GC (do most of the object marking while other threads running), and whether it is a preserving GC (keep soft references).

Your typical GC is triggered by a soft allocation limit, only freeing on the active heap, concurrent, and preserving. On the other extreme the GC triggered before an OutOfMemoryException is full, synchronous, and non-preserving.

(cit. Android Development: How does garbage collection work in Android Dalvik? - Quora)

Dopo questo ho trovato delle slides grandiose: http://dubroy.com/memory_management_...droid_apps.pdf
Questo invece sono gli appunti presi da qualcuno durante la presentazione delle slides di prima: http://static.googleusercontent.com/...Management.pdf

Da questo si capisce che non possiamo intuire se stiamo in una situazione di garbage collecting frequente semplicemente analizzando le occupazioni di memoria dei processi. Ciò significa che dobbiamo analizzare i log. Dall'analisi dei log siamo in grado di recuperare gli eventi di esecuzione de GC relativi a:

• Heap quasi pieno (pieno oltre una soglia)
• Heap pieno (ovvero prima di un potenziale lancio dell'eccezione java.lang.OutOfMemoryError)

A questo punto fatto N il numero di processi attivi, data M la dimensione della memoria e calcolato attraverso il log H, numero di esecuzioni del GC nell'unità di tempo avvenuti a fronte di eventi relativi al riempimento dell'heap, si avrà:

s ~ M/(N*H)

dove s è la dimensione ottima dell'heap.

Quello che si può fare è analizzare comportamenti medi (in base all'utilizzo tipico del singolo utente) relativi a N ed H. Questo si può fare parsando i log in background con una applicazione ad-hoc che poi magari calcola "s" (considerando analisi di lungo periodo) e modifica dalvik.vm.heapsize.

Tuttavia la formula che ho determinato non è una formula: dice solo che la dimensione ottima dell'heap è direttamente proporzionale alla memoria disponibile e inversamente proporzionale al prodotto tra il numero di processi attivi e il numero di esecuzioni del garbage collector nell'unità di tempo.

Inoltre in realtà H è funzione di "s". Perciò se H(s) non si può approssimare bene con una funzione lineare (e a meno di qualche costante) la formula non sarà calcolabile in forma chiusa. Quindi andrà anche definito un metodo matematico per il calcolo della soluzione.

Se facciamo l'applicazione, secondo me realizziamo qualcosa di veramente figo

[samurri]

bravo, mi sono avvicinato a questa faccenda per capire certi strani comportamenti di questo telefono e la questione heap mi ha subito colpito. Dalla tua ricerca ho trovato molte conferme ma non riesco per poca dimestichezza a capacitarmi di quante volte nell'uso normale si possono raggiungere queste situazioni di pieno riempimento.
questo è importante perché rende l'idea di quanto un'ottimizzazione di questo genere possa portare dei benefici a molti.

Inviato dal mio GT-S5570I usando Androidiani App

[Ikon]

Secondo me una idea ce la possiamo fare analizzando i log come indicato nelle slides. Se esistono applicazioni che frequentemente generano attivazioni del GC allora può avere un senso. Quanto ognuno dei fattori M, K, N e H sia veramente positivo/negativo in termini di peso sulle prestazioni complessive determina vari parametri adimensionali che complicano la formula e fanno sì che alla fine:

s = f(M, K, N, H)

approssimi molto bene la dimensione ottima dell'heap.

[Michelasso]

dunque io uso VM heap size ed il massimo impostabile è 64mb e a default è 64mb. Ho provato 28mb senza notare alcunchè, Michelasso ha impostato 8 mb e ha avuto continui bootloop.
In rete ho trovato che il default di gingerbread è 24, di honeycomb è 48, il resto l'ho scritto sopra

Ti ho già risposto che il default della nostra ROM, che è standard Gingerbread, è 64MB. A meno che non intendessero la dimensione minima dell'heap a seconda della versione di Android. Li il discorso cambia perché come abbiamo visto se l'heap è troppo piccolo Zygote non riesce a caricare tutte le classi. E naturalmente versioni superiori di Android hanno più classi di maggiore dimensione. Anche se il doppio mi pare francamente troppo, ma è pure vero che Honeycomb è solo per i tablet (che si spera abbiano più memoria!)

In sostanza:

• ogni istanza della Dalvik si ciuccia N = dalvik.vm.heapsize megabyte di memoria. Quindi più istanze ci sono più swap-in/swap-out ci sono in caso di saturazione della memoria.
• Tuttavia avere un heap più grosso permette di diminuire il numero di esecuzioni del Garbage Collector (quando l'heap è in saturazione).

Perfetto vai... ci sono arrivato! Adesso sono allineato a quello che dicevate. Ragionare ad alta voce anche sui forum aiuta :P

Aumentare l'heap size permette di ridurre il numero di esecuzioni del GC se l'uso del heap da parte delle applicazioni è vicino alla saturazione, ma al tempo stesso può ridurre in numero max di applicazioni attive concorrenti. Quindi invece di eseguire il GC ti ritrovi a dover ricaricare tutta l'applicazione, perché questa viene uccisa dall'application manager.

Boh.. Non mi sembra che si discosti molto da quanto dicevo. Zygote a parte, che non sapevo che contenesse tutte le classi Android. La cosa che non ho capito e se questo heap viene preallocato dal kernel per ogni applicazione. Se fosse così un heap troppo grande sarebbe un disastro. Quello troppo piccolo già lo è come abbiamo visto.

bravo, mi sono avvicinato a questa faccenda per capire certi strani comportamenti di questo telefono e la questione heap mi ha subito colpito. Dalla tua ricerca ho trovato molte conferme ma non riesco per poca dimestichezza a capacitarmi di quante volte nell'uso normale si possono raggiungere queste situazioni di pieno riempimento.
questo è importante perché rende l'idea di quanto un'ottimizzazione di questo genere possa portare dei benefici a molti.

Questa invece non l'ho capita. Quali benefici? Meglio avere un heap più piccolo che permetta di avere più applicazioni in memoria ma che esegue più spesso il garbage collector, se mai viene eseguito, oppure uno più grande con più applicazioni che devono essere fatte ripartire perché vengono uccise più spesso dall'Application Manager? Oppure la via di mezzo come effettivamente sembra che abbiamo?

E' come per il discorso dell'applicazione ipotizzata da Ikon. Tale applicazione avrebbe poco senso in un telefono general purpose. Quelle considerazioni si fanno per il tuning di server che si sanno eseguire solo una mansione/servizio/applicazione e quindi possono beneficiare di particolari settaggi perché il loro tipo di uso sarà più o meno costante nel tempo. Ma dato l'utilizzo di un giorno del telefono e calcolando su quello l'heap size per il prossimo reboot, può capitare e capiterà sicuramente che l'utente faccia la volta dopo un uso totalmente diverso. Come del resto l'uso può cambiare di ora in ora.

Bah. In ogni caso ho appena fatto la prova del 9. Ho testato con 24MB e 124MB (valore max consentito in ROM Tollbox Pro). A mio avviso non cambia una pippa. Ho aperto 6 applicazioni e sono passato da una all'altra via tenendo premuto Home. Google Play non viene mai ucciso, si vede perché si riapre subito con già tutte le icone caricate, Whatsapp torna dov'era ma ci mette un po' ad aprirsi, Agenda lo stesso, facendo pensare che le applicazioni in realtà fossero terminate e tornino al punto dove erano state lasciate (come dovrebbero), Freespace ci mette un po' ma imbroglia, se ho aperto un grafico e mi sposto su di un altro, poi riaprendolo torna al primo grafico. Che non dovrebbe succedere, a meno che appunto l'applicazione non fosse stata terminata. Stesso identico comportamento per tutte con i due valori di heap space menzionati. Ah, GO Task Manager Ex riporta sempre la stessa memoria consumata in entrambi i casi (cioè, tre casi: lo stesso con l'heap di 64MB).

Credo che il discorso sia semplice: Zygote ha un heap grande e quindi le applicazioni consumano di solito meno. Così non si notano differenze. Con L'heap che a questo punto viene a sua volta allocato dinamicamente dalla gestione della memoria virtuale del kernel (paging) e perciò anche sovradimensionato non darà mai problemi reali di memoria (a livello di RAM allocata dal kernel).

[samurri]

Non ho capito io questa volta il tuo intervento hai rifatto i test già fatti e ridetto le stesse cose. bisogna vedere i log per capire l'effetto e l'efficacia di questa modifica e, alla luce di quanto detto forse e dico forse, 64MB di default è troppo. quindi l'heap size è unico? 64mb ad esempio è fisso e viene dinamicamente occupato da n applicazioni? devo rivedere alcune cose che sono state postate

Inviato dal mio GT-S5570I usando Androidiani App

[Michelasso]

Non ho capito io questa volta il tuo intervento hai rifatto i test già fatti e ridetto le stesse cose. bisogna vedere i log per capire l'effetto e l'efficacia di questa modifica e, alla luce di quanto detto forse e dico forse, 64MB di default è troppo. quindi l'heap size è unico? 64mb ad esempio è fisso e viene dinamicamente occupato da n applicazioni? devo rivedere alcune cose che sono state postate

Inviato dal mio GT-S5570I usando Androidiani App

Quali test già fatti? Hai fatto il test cambiando l'heap size a 24MB e 124MB? O comunque a due valori estremi? E perché 64MB sarebbe troppo? Se è come dico io, e altrimenti non dovrebbe essere, l'heap size potrebbe avere anche la dimensione di tutta la RAM che non cambia un tubo. Perchè Dalvik introduce un secondo livello della gestione della memoria. Sotto ci sta ovviamente la gestione della memoria paginata del kernel, la stessa che viene usata dalla swap, ma che è utilizzata anche se la swap non esiste.

In pratica il discorso è semplice, ed è una delle prime cose che si insegnano a informatica: il kernel alloca pagine di RAM solo quando queste sono richieste. Quando un apk parte non carica tutte le sue classi in memoria. Carica solo quelle che vengono richieste, quando vengono richieste. Quando richiede una sua classe, che avrà bisogno di un certo spazio in RAM, il kernel, che ha già mappato queste classi in uno spazio di memoria virtuale si preoccupa di allocare le pagine in RAM necessarie, e caricarle dal supporto di I/O, sia questo una memoria flash, un hard disk o anche un lettore di schede (gli ultimi 2 non ci sono in Android, ma se ci fossero il concetto sarebbe quello). Questo se viene generato un fault perché la classe, o meglio il codice, in RAM non esiste.

Se invece l'apk ha bisogno di classi, oggetti del Zygote, li accede normalmente perché sono già nell'heap di Zygote. Dopo averli però mappati nello spazio di memoria virtuale dell'apk. Ma allocati come copy-on-write. Che significa allocare memoria come copy-on-write? Che il kernel, fintantoché quelle pagine di memoria condivisa vengono accedute solo in lettura, continuerà ad utilizzare le stesse pagine RAM per quelle classi di Zygote. Se per qualche motivo c'è la necessità di eseguire un write, e quindi sporcare tali pagine (modifica dei dati), il kernel prima di eseguire il write farà un clone della pagina RAM che l'apk deve accedere, e rimapperà lo spazio di memoria virtuale dell'apk per scrivere in quella pagina e non più in quella condivisa da Zygote.

In ogni caso cosa comporta avere una dimensione piccola dell'heap? Che alcuni apk possono allocare e rilasciare memoria di continuo. Questo processo porta a una frammentazione dell'heap che a un certo punto dovrà essere "ricompattato", "riordinato", eseguendo il garbage collector. Il quale altro non fa che prendere tutti i segmenti di memoria che sono stati rilasciati (marcati come liberi) e unirli cercando di ottenere segmenti continui più grandi per far spazio a una nuova richiesta di memoria da parte dell'apk (qui siamo a livello Dalvik, non a livello kernel. Ogni garbage collector ha i suoi algoritmi per essere più o meno ottimizzato e di sicuro non mi addentrerò in quello di Dalvik di Android, perché sinceramente questa ciofeca con macchine virtuali potevano fare anche e meno di implementarla). Quando a furia di allocare e rilasciare non ci sarà più un segmento grande abbastanza per allocare lo spazio richiesto, parte il garbage collector. Se anche dopo il GC a causa di troppa frammentazione tale segmento non esiste l'apk va in fault per mancanza di memoria. Il che significa che un heap size troppo piccolo non è bello. Anche se tale situazione non dovesse mai verificarsi si avrebbero comunque dei GC più o meno periodici.

Dimensionando quindi un heap size più grande riduci il numero di possibili esecuzioni del GC e soprattutto di eventuali fault. Ma se gli apk sono piccole applicazioni dal bisogno modesto di risorse, che una volta allocata un'area nell'heap quella si tengono, la dimensione dell'heap size, purché adeguata per tenere l'heap di Zygote, diventa del tutto ininfluente. Il che sembra essere appunto il caso della maggioranza delle applicazioni che utilizziamo. Forse i giochi e i web browser possono dare più problemi di prestazioni, in quanto trattano maggiori moli di dati in scrittura. Un maggior valore di default per l'heap size potrebbe aiutare? Non lo so. Potrebbe esserci anche la possibilità che le applicazioni possano ignorare quel valore e stabilire loro stesse la dimensione dell'heap. Ma per la maggioranza delle applicazioni mi pare che il problema non si ponga. Dando un'occhiata veloce alla memoria occupata da queste si vede che al massimo consumano sui 20MB, quindi ben al di sotto dei 64MB di default del nostro telefono, ma anche dei 24MB che forse sono il valore minimo per Zygote.