Heap Size

[samurri]

Smanettando qua e là mi sono accorto che nalla rom stock del nostro next turbo, tramite VM Heap Size il valore impostato è 64mb. Ho letto in rete che questo valore dovrebbe essere ideale a quantitativi di ram di circa 2GB, cosa che nel nostro caso è quasi 10 volte maggiore (290 Mb).
Facendo una proporzione con quanto consigliato in rete, tale valore dovrebbe aggirarsi sui 28Mb. Qualcuno ha informazioni in merito oppure ha già effettuato dei test?
Mi vien da pensare che un valore così alto in un quantitativo così basso non si tratti di un errore ma di una scelta ben precisa in modo da migliorare la fluidità a discapito del multi tasking. Cosa ne pensate?

[Michelasso]

Da quanto ho capito io VM sta per [Dalvik] Virtual Machine. E' la memoria massima allocabile da ogni macchina virtuale (applicazione Android) e non ha nulla a che fare con il multitasking e/o la RAM massima. Se la rendi troppo piccola c'è il rischio che le applicazioni non partano o chiudano per memoria insufficiente. "heap" in informatica è il "mucchio" da dove si preleva la memoria dinamica, ossia allocata al momento. In altre parole mi sa tanto che sia uno di quei parametri che in assoluto non vanno toccati. Le applicazioni devono essere dimensionate a priori per non usare più di 64MB.

[Ikon]

Le applicazioni devono essere dimensionate a priori per non usare più di 64MB.

Non sulla dalvik ma in altre applicazioni mobile in JAVA dove però avevo molta più ram (sull'apparecchio girava win7), ho avuto bisogno di modificare questo settaggio a causa della mole di dati gestiti. Diciamo che è un buon valore, difficilmente lo saturerai ottenendo il fault delle applicazioni con un "java.lang.OutOfMemoryError: Java heap space". In quel caso tiralo un po' su. Analogamente se non ti servono 64MB, ma sei sicuro che ne utilizzerai molti meno allora potresti tirarlo giù a 16MB o 32MB. Ripeto sto parlando di una VM Java classica, dove:

java -Xms16m -Xmx128m my_app

lancia my_app con 16MB iniziali e 128MB massimi.

[samurri]

Da quanto ho capito io VM sta per [Dalvik] Virtual Machine. E' la memoria massima allocabile da ogni macchina virtuale (applicazione Android) e non ha nulla a che fare con il multitasking e/o la RAM massima. Se la rendi troppo piccola c'è il rischio che le applicazioni non partano o chiudano per memoria insufficiente. "heap" in informatica è il "mucchio" da dove si preleva la memoria dinamica, ossia allocata al momento. In altre parole mi sa tanto che sia uno di quei parametri che in assoluto non vanno toccati. Le applicazioni devono essere dimensionate a priori per non usare più di 64MB.

Non la penso così, e non credo nemmeno si tratti di un parametro a cui le applicazione devono tener più di tanto conto. In parte è vero ciò che dici ovvero dovrebbe trattarsi di una speci di buffer di una certa dimensione il quale se sovrariempito genera delle operazioni I/O eliminando i dati vecchi con i nuovi. Ciò occupa CPU e può generare consumi maggiori e/o rallentamenti.

Non sulla dalvik ma in altre applicazioni mobile in JAVA dove però avevo molta più ram (sull'apparecchio girava win7), ho avuto bisogno di modificare questo settaggio a causa della mole di dati gestiti. Diciamo che è un buon valore, difficilmente lo saturerai ottenendo il fault delle applicazioni con un "java.lang.OutOfMemoryError: Java heap space". In quel caso tiralo un po' su. Analogamente se non ti servono 64MB, ma sei sicuro che ne utilizzerai molti meno allora potresti tirarlo giù a 16MB o 32MB. Ripeto sto parlando di una VM Java classica, dove:

java -Xms16m -Xmx128m my_app

lancia my_app con 16MB iniziali e 128MB massimi.

Ho trovato in merito questi riferimenti in rete che indicano dimensionamenti della porzione di questo "buffer" assegnata ad ogni app:

Gingerbread a default → 24m heap
512mb ram → 40-48m heap
1GB → 64mb

noi ne abbiamo 290, ho fatto una proporzione ed ho impostato 28m e vediamo che succede.
Cmq se è troppo piccolo può accadere quello che dice Michelasso, se è troppo grande siccome vengono date 64m a tutte le applicazioni, un multitasking di più di 4-5 applicazioni dovrebbe genera rallentamenti importanti, soprattutto nell'I/O. Ora se apro 2-4-6 applicazioni di cui una è sempre Antutu e lancio un test i valori potrebbero essere indicatori di un simile comportamento?

@michelasso: sai per caso quanta ram occupa Go Launcher persistente nel sistema?

EDIT: una possibile definizione di heat: un’area di memoria dinamica allocata per permettere alle applicazioni in esecuzione di poggiarci sopra i loro dati, appunto dinamicamente. In questo modo i dati delle applicazioni vengono richiamati molto velocemente, proprio perché l’accesso alla RAM è molto più veloce che accedere alle memorie flash. Quindi in linea teorica più è grande il valore della VM Heap Size e più il sistema sarà veloce perché tutte le applicazioni lavorano in RAM, ma ciò aumenterà anche la durata della batteria, perché l’I/O su memoria esterna sarà molto più ridotto … In altre parole VM Heap Size è una sorta di cache per le applicazioni.

EDIT2: il test antutu col solo benchmarck aperto non riporta differenze sostanziali modificando il valore da 64 a 28. I test fatti in performance/sio danno valori sempre simili tra loro anche per quanto concerne il Database I/O.

EDIT3: con 5 applicazioni attive nel task manager antutu mi ha dato addirittura il miglior test di sempre 2068 ma non nei valori significativi... solo grazie ai bench sulla sd

[Michelasso]

Non la penso così, e non credo nemmeno si tratti di un parametro a cui le applicazione devono tener più di tanto conto. In parte è vero ciò che dici ovvero dovrebbe trattarsi di una speci di buffer di una certa dimensione il quale se sovrariempito genera delle operazioni I/O eliminando i dati vecchi con i nuovi. Ciò occupa CPU e può generare consumi maggiori e/o rallentamenti.

Ho trovato in merito questi riferimenti in rete che indicano dimensionamenti della porzione di questo "buffer" assegnata ad ogni app:

Gingerbread a default → 24m heap
512mb ram → 40-48m heap
1GB → 64mb

Non so dove tu abbia trovato quei valori, ma Gingerbread, giudicando dal /system/build.prop del nostro telefono usa un default di 64MB: dalvik.vm.heapsize=64m

Nè io, né sicuramente Zack abbiamo toccato quella linea, quindi, al solito, attento alle fesserie che trovi in giro nel mondo Android.

Poi bisogna vedere come funziona l'heap in Java/Dalvik. Ikon sicuramente ne saprà più di me. Se quei 64MB o quanti sono vengono allocati subito per ogni applicazione/macchina virtuale (mi parrebbe strano, ma con Android tutto è possibile) allora si, è chiaro che aumentandone il valore avresti meno applicazioni residenti in memoria allo stesso tempo. Che visto come gira nel Next Turbo è anche possibile se non probabile a dire il vero. Alzandolo in questo caso faresti peggio, perché riduci la memoria disponibile per le seconde applicazioni.

Diminuendolo che capita? Se le applicazioni vanno in fault, come dice Ikon, sei fregato. Semplicemente non puoi diminuirlo. Se invece le Dalvik Machine implementano un meccanismo per togliere degli oggetti liberando spazio per altri, dopo avere fatto girare un garbage collection allora è possibile che tutte le applicazioni girino sempre ma con performance ridotte. Cosa che, di nuovo, non so.

Aggiungi il fatto che Android ha la sua gestione personale di memoria la quale ammazza le applicazioni attive per far spazio in memoria. In altre parole un bordello immane. Che puoi complicare ulteriormente attivando la swap e quindi la Virtual Memory (quello che VM è sempre stato a casa mia), che non si capisce come interagisca con tutto quanto scritto sopra e quindi apposta ti dicevo che se vuoi abilitarla devi capire e trovare quali sono i parametri migliori. Ma non a tentativi, con una deduzione logica dati gli elementi che ci sono in gioco.

Per quanto riguarda quanta memoria usi GO Launcher non lo so. Sinceramente non è una questione che mi pongo, tanto il multitasking in questo telefono non è che serva granché, mal che vada le applicazioni vengono terminate e se mi servono di nuovo le faccio ripartire.

Non sulla dalvik ma in altre applicazioni mobile in JAVA dove però avevo molta più ram (sull'apparecchio girava win7), ho avuto bisogno di modificare questo settaggio a causa della mole di dati gestiti. Diciamo che è un buon valore, difficilmente lo saturerai ottenendo il fault delle applicazioni con un "java.lang.OutOfMemoryError: Java heap space". In quel caso tiralo un po' su. Analogamente se non ti servono 64MB, ma sei sicuro che ne utilizzerai molti meno allora potresti tirarlo giù a 16MB o 32MB. Ripeto sto parlando di una VM Java classica, dove:

java -Xms16m -Xmx128m my_app

lancia my_app con 16MB iniziali e 128MB massimi.

E' possibile che Dalvik in Android usi un valore minimo di zero MB? Sul dimensionamento, poiché non è possibile modificarlo dall'utente normale (serve root) son propenso a credere che quella dimensione debba rientrare nelle specifiche di sviluppo della applicazioni. Ma come avrai letto non è la mia materia.

PS: Ho fatto una prova, e ho messo l'heap a 8MB. Ovviamente per testarlo nel caso estremo. Risultato? Bootloop continuo. Crash delle applicazioni di sistema. Samurri, lascia perdere. Come ho detto è uno di quei valori dai quali è meglio starci distanti.

[samurri]

Il problema è che dai test che ho fatto non è cambiato nulla e posso ipotizzare per 2 ragioni: non ho usato gli strumenti giusti per valutare la differenza oppure non ho usato un mix tra valore heap e garbage collection adeguato. Chiaro che questa questione potrebbe essere lunghissima e non generare parametri standard individuabili come possibili ottimizzazioni perchè è legata all'uso che se ne fa del telefono. Il valore 64mb è il massimo impostabile e "dovrebbe" essere il più conservativo sul lato batteria e forse ha dietro anche una sua logica, ovvero su un terminale così limitato come il nostro e con una batteria così piccola, quante applicazioni possono girare simultaneamente? poche, e che senso ha averne fluide 10 invece di 5 se 10 magari uccidono la batteria nel solo istante che le hai tutte in funzione? meglio poche fluide e che risparmiano la batteria, al massimo scatta un rallentamento a causa delle operazioni I/O di svuotamento riempimento.
Una prova sarebbe vedere che succede se mpostassi il valore heap ad 1: in linea di principio potrei non ottenere errori di memoria insuff, ma solo tempi disumani di caricamento di un'applicazione ma devo fare un backup prima o rischio di dover ripristinare con odin.
Esiste un task manager per android simile a quello di windows per valutare il carico sulla cpu e sulla ram, magari da poter controllare accanto all'indicazione della batteria?

@miché: hai usato vm heap size per impostare il valore a 8?

[Michelasso]

Ho usato ROM Toolbox Pro il quale modifica il build.prop che è l'unico posto dove va settato quel valore visto che deve valere per tutti. Poi via "adb shell" l'ho ripristinato a 64m quando l'UI di Android allegramente se ne andava in bootloop. Ovviamente ho fatto un reboot fisico del telefono dopo il ripristino al valore standard.

In ogni caso il discorso è semplice: questi telefoni sono progettati per telefonare, navigare in Internet e far girare una applicazione alla volta più i widget. Nulla di che, e quel lavoro lo fa anche bene. Se poi volete prestazioni più veloci e/o una batteria più capiente allora comprate un telefono di fascia alta. Io l'unico tweak che veramente ho visto produrre qualche risultato è il setting del minfree per la memoria. Quello che stabilisce quando Android chiude le applicazioni. A me, pare, che il telefono laggi un po' meno. Forse perché avendo meno applicazioni attive (vengono chiuse) la CPU ha meno lavoro da fare...

[Ikon]

Mi sono documentato un attimino. Ho scoperto alcune cose carine. Magari sarò banale, comunque cito i riferimenti perchè possono tornare utile a qualcuno che legge il thread. Potrei dire anche qualcosa di scontato ai più, comunque se un non addetto ai lavori legge il post vorrei che riesca a capire lo stesso.

Dalvik was originally written by Dan Bornstein

(cit. Dalvik (software) - Wikipedia, the free encyclopedia)

The Dalvik heap is preloaded with classes and data by zygote (loading over 1900 classes as of Android version 2.2). When zygote forks to start an android application, the new application gets a copy-on-write mapping of this heap. As Dan Borstein says below, this helps with memory reduction as well as application startup time.

Dalvik, like virtual machines for many other languages, does garbage collection on the heap. There appears to be a separate thread (called the HeapWorker) in each VM process that performs the garbage collection actions. (See toolbox ps -t)
Dan Borstein said this about heap sharing:

"It's used in Android to amortize the RAM footprint of the large amount of effectively-read-only data (technically writable but rarely actually written) associated with common library classes across all active VM processes. 1000+ classes get preloaded by the system at boot time, and each class consumes at least a little heap for itself, including often pointing off to a constellation of other objects. The heap created by the preloading process gets shared copy-on-write with each spawned VM process (but again doesn't in practice get written much). This saves hundreds of kB of dirty unpageable RAM per process and also helps speed up process startup."

(cit. Android Memory Usage - eLinux.org)

A questo punto chiarirei anche il concetto di heap, perchè non so voi ma io sono più di 5 anni che l'ho studiato e non mi ricordo "una beata m****a"!

Heap (or free store), an area of memory used for dynamic memory allocation.

(cit. Heap - Wikipedia, the free encyclopedia)

Senza farci troppe seghe mentali su segmentazione, virtualizzazione, paginazione e compagnia cantando (perchè sennò mi ritirano la laurea), dividerei la memoria (virtuale, cioè come la vede una applicazione) in stack ed heap. Se pensiamo che lo stack cresca dal basso verso l'alto (con strategia LIFO), l'heap cresce dall'alto al basso (la strategia di allocazione non è lineare come per lo stack).

Mentre lo stack accoglie valori come contenuto dei registri, indirizzi, parametri e variabili automatiche per permettere chiamata e ritorno delle funzioni, l'heap accoglie le variabili dinamiche. Considerando che stiamo parlando di JAVA allora possiamo dire che l'heap accoglie "tutta" la memoria impiegata all'interno di un processo.

Per la Dalvik mi sembra di capire che allo startup del sistema Zygote carichi tutte le librerie (un botto) nello heap. Quando è tutto pronto, i processi VM si ritrovano a condividere lo stesso heap. Per evitare problemi è usata banalmente una tecnica di copy-on-write: in sostanza l'heap viene copiato e le modifiche vengono effettuate sempre sulla copia, però poi vengono riportate consistentemente sull'originale al fine di evitare concorrenza.

Perciò da questo ne deduco che:

• la dimensione minima dello heap deve essere almeno pari a tutta la fuffa che Zygote carica al boot
• la dimensione massima dello heap è al max quella della memoria fisica
• una buona dimensione dello heap della Dalvik non dipende dall'applicazione come nella VM Java classica

Se mettete un valore spropositato tipo 290Mb cosa vi succede?

[samurri]

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

[Ikon]

Ok ho trovato qualcosa di davvero interessante:

It’s not “virtual memory,” it’s real memory. This setting is simply the maximum amount of heap space (read: memory) a single instance of the Dalvik VM (read: application) can obtain.

The only scenario where it would be beneficial to increase the maximum heap size would be if you have an application that is very close to using up all of its available heap space, which would force it to run garbage collection frequently, which would use up CPU cycles. It is possible that lowering the maximum heap size could be beneficial in that it might prevent an application from obtaining more memory than it needs (by forcing it to garbage collect sooner), but that all depends on how the Dalvik VM is implemented and is really beyond my knowledge.

It is the memory allocated to the dalvik virtual machine increasing it will use more memory if the apk calls for it and decreasing will use less,but go into garbage quicker thus making the apk perform less efficiently. This has to do with reading java code increasing the dalvik.vm will probably make no noticeable differences.

Actually, I would suggest bumping up VM heap space to maximum because it reduces GC runs to only when strictly necessary – and *any* GC algorithm is costly. In short, at the expense of little memory (that you wouldn’t be using anyway) you get applications that perform smoother plus lower battery usage.

(cit. What is Dalvik VM Heapsize? benefits and downfalls? « butterflydroid)

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