Uno dei problemi che affliggeva Hybris sin dalla primissima release era il problema dell’utilizzo/spreco di memoria .

Chi si è cimentato nella lettura del codice, avrà probabilmente notato che nella funzione htree_execute , quella che in pratica deve eseguire l’alberazione del programma parserizzato, non venivano de allocati gli oggetti “deallocabili” .

Questo avveniva per due ragioni principali :

1. Essendo una funzione fortemente ricorsiva, non si poteva stabilire a priori se un dato oggetto sarebbe stato necessario ad una ricorsione successiva od alla ricorsione “chiamante”.
2. Data la forte generalizzazione della classe “Object“, non era facile stabilire a priori quali tipi di oggetto era possibile deallocare e quali no.

Ebbene, la soluzione era molto più semplice del previsto in effetti ed il non averla trovata prima dipendeva dal fatto che il codice di htree_execute era abbastanza incasinato (di fatto era una delle pochissime funzioni che era rimasta praticamente invariata fin dall’inizio) e non era molto facile stabilire un criterio del genere in base all’ “impatto visivo” del codice stesso.

Quindi, mi son messo e l’ho ripulita, creato una funzione “esecutrice” per ogni tipo di nodo e dividendo il mega switchone di htree_execute dal codice operativo di ogni alberazione sintattica, giungendo alla conclusione che, un oggetto è immediatamente deallocabile se e solo se :

1. Non è una variabile globale dichiarata nell’area di memoria principale del programma.
2. Non è una variabile locale dichiarata nello stack frame della funzione in cui ci si trova.
3. Non rappresenta un valore costante (un numero, una stringa, ecc non derivanti da un espressione che li compone).

Dedotto questo, è stato relativamente semplice modificare ulteriormente il codice, creando la funzione hybris_vg_isgarbage per determinare se un dato oggetto è deallocabile tramite questo criterio e la macro H_GC_COLLECT per liberare memoria in modo smart e sicuro .

Detto ciò, ovviamente la questione presenta sia dei pro che dei contro .

Il pro principale è che vengono utilizzate MOLTE meno risorse rispetto a prima per quanto riguarda la RAM, il che è ottimo per un programma che deve rimanere in esecuzione per parecchio tempo (un server ad esempio) o che richiede molte ricorsioni, loop ecc che vanno ad allocare spazzatura sullo stack (vedi gli esempi per calcolare numeri primi e perfetti).

Il contro, come è facile immaginare, è che controllare ogni puntatore per determinare se è allocabile, scorrendo i vettori di due frame di memoria, rallenta un po la velocità di elaborazione, ho notato un incremento di circa 10ms nel programma per il calcolo dei numeri primi rispetto a prima .

Per questo motivo, l’utente è in grado di scegliere se utilizzare questa funzionalità in fase di compilazione dei sorgenti di Hybris, andando ad agire sulla costante GC_SUPPORT definita nel file config.h, la quale ovviamente se è definita attiverà le funzionalità di garbage collecting, mentre se verrà commentata lascerà la gestione della memoria come prima, allocando tutto il necessario a runtime e deallocando tutto ciò che è stato allocato alla fine del programma, tuttavia non liberando alcuni blocchi di memoria dei quali non è possibile tener traccia, ovvero proprio quelli de allocabili tramite il garbage collector .

Detto questo, son felice di dichiarare che con questa consistente modifica, l’ultima versione di Hybris risolve il 99% dei memory leaks, lasciandone solo altri pochi che comunque ho il dubbio siano dei falsi positivi di Valgrind (un software fatto proprio per determinare i memory leaks in un programma e che sto usando intensamente in questi giorni) ^^

Popularity: 8% [?]

Ti potrebbe interessare:

1. Gestione “Smart” Della Memoria In Hybris : Parte II . Come detto nell’ultimo articolo, negli ultimi commit di Hybris è...
2. Hybris : Rivoluzionato il sistema di gestione dei tipi ed il garbage collector. So che avevo detto che non avrei parlato più di...
3. Prima bozza della documentazione sullo sviluppo dei moduli Come da titolo, è pronta una prima bozza della documentazione...
4. [IMPORTANTE] Hybris 1.0 Roadmap, ho bisogno di consigli user-side A volte staccare la spina (nel mio caso il cervello)...
5. Hybris memory lookup, now Google powered!!! No, non ho inserito un motore di ricerca dentro Hybris...