Nell’articolo avevo anche detto che questo sistema, nonostante avesse il vantaggio di diminuire drasticamente l’utilizzo della memoria durante l’esecuzione di uno script, aveva lo svantaggio di diminuire anche le prestazioni complessive dato com’era strutturato l’algoritmo per determinare se un dato oggetto era deallocabile durante l’esecuzione dello script stesso, algoritmo che effettuava diversi controlli, tra i quali due loop (quelli che rappresentavano maggiormente il collo di bottiglia) sul frame della funzione chiamante e su quello della memoria principale.

Ebbene, sono un coglione XD .

Si avete letto bene, sono un coglione perchè avevo strutturato l’algoritmo ragionando “a posteriori” senza pensare che prevenendo questo controllo si poteva risolvere il problema ed aumentare anche le prestazioni rispetto a prima .

Quello che intendo è che nella classe Object, ho inserito una bitmask chiamata “attributes” che, come suggerisce il nome stesso, rappresenta gli attributi di quell’oggetto in particolare, ovvero se è un alias, una costante e soprattutto se è deallocabile .

Quest’ultimo flag in particolare, viene impostato alla creazione dell’oggetto a 1, quindi nello stato iniziale qualunque oggetto è de allocabile, successivamente, resetto il flag se e solo se si verificano le condizioni di non deallocabilità immediata, cioè se :

1. L’oggetto viene definito in un qualunque frame (sia di una funzione che quello principale) come variabile .
2. L’oggetto è una costante .

Quindi, impostando questo flag nella maschera binaria solo quando serve, al processo di garbage collection basta controllare a posteriori se sono impostati o meno i flag giusti per determinare se è possibile deallocare l’oggetto, eliminando così il problema dei due loop e del controllo complesso che prima rallentava di parecchio l’esecuzione di uno script.

Insomma come dire, a volte basta ragionare in modo “speculare” a come si ragiona in partenza per risolvere un problema

Nota: Quando parlo di calo di prestazioni significante, mi riferisco comunque a rallentamenti nell’ordine di millisecondi in algoritmi molto complessi che, per motivi di test, sono strutturati appositamente per allocare molta memoria e “stressare” l’interprete . In realtà, in programmi “normali” che non richiedono chissà quale elaborazione avanzata, la differenza non si nota nemmeno .

Related posts:

1. Gestione “smart” della memoria in Hybris .
2. Hybris : Rivoluzionato il sistema di gestione dei tipi ed il garbage collector.
3. Hybris memory lookup, now Google powered!!!

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) ^^

Related posts:

1. Gestione “Smart” Della Memoria In Hybris : Parte II .
2. Hybris : Rivoluzionato il sistema di gestione dei tipi ed il garbage collector.
3. Prima bozza della documentazione sullo sviluppo dei moduli