8/3/2019 Gestione automatica della memoria dinamica in C e C++

1/7

CP pensareprogettareprogrammare n. 137 luglio-agosto 2004

Gestione automatica della

memoria dinamica in C e C++di Gianluca InsolvibileLa Garbage Collection non e un privilegio riservato ai soli programmatori Java e C#: gra-zie alla libreria di Hans Boehm e possibile dotare i propri programmi C e C++ di questocomodo strumento. Ma i programmatori C/C++ di lunga data ne saranno entusiasti?

Gianluca Insolvibile

E laureato in Ingegneriadelle Telecomunicazio-ni. Si occupa di networ-king su reti TCP/IP e ATMe di video digitale pres-so il Centro META delConsorzio Pisa Ricerche.

8/3/2019 Gestione automatica della memoria dinamica in C e C++

2/7

pubblicato suWWW.INFOMEDIA.IT

stampa digitale da

Lulu Enterprises Inc.

stores.lulu.com/infomedia

Infomediamedia e limpresa editoriale che da quasi venti an-

a raccolto la voce dei programmatori, dei sistemi-

dei professionisti, degli studenti, dei ricercatori e dei

essori dinformatica italiani.

o piu di 800 gli autori che hanno realizzato per le te-

Computer Programming, Dev, Login, Visual Basic

nal e Java Journal, molte migliaia di articoli tecnici,

entazioni di prodotti, tecnologie, protocolli, strumen-lavoro, tecniche di sviluppo e semplici trucchi e stra-

mmi. Oltre 6 milioni di copie distribuite, trentamila

ne stampate, fanno di questa impresa la piu grande ed

ente realta delleditoria specializzata nel campo della

rammazione e della sistemistica.

tti questi anni le riviste Infomedia hanno vissuto del-

assione di quanti vedono nella programmazione non

la propria professione ma unattivita vitale e un vero

rtimento.

2009, Infomedia e cambiata radicalmente adottando

uovo modello aziendale ed editoriale e si e organiz-

attorno ad una idea di Impresa Sociale di Comunita,

ecipata da programmatori e sistemisti, separando le

ita di gestione dellinformazione gestite da un board

unitario professionale e quelle di produzione gesti-

a una impresa strumentale. Questo assetto e in linea

le migliori esperienze internazionali e rende Infome-

ancora di piu parte della Comunita nazionale degli

uppatori di software.

media e media-partner di manifestazioni ed eventi in

ito informatico, collabora con molti dei pi u impor-

editori informatici italiani come partner editoriale e

itore di servizi di localizzazione in italiano di testi in

ua inglese.

aginazione automatica di questa rivista e realizzata al

% con strumenti Open Source usando OpenOffice,

cs, BHL, LaTeX, Gimp, Inkscape e i linguaggi Lisp,

hon e BASH

copyright information about the contents of Compu-

Programming, please see the section Copyright at

end of each article if exists, otherwise ask authors.media contents is 2004 Infomedia and released as

ative Commons 2.5 BY-NC-ND. Turing Club content

2004 Turing Club released as Creative Commons

BY-ND.

nformazioni di copyright sul contenuto di Computer

gramming sono riportate nella sezione Copyright

fine di ciascun articolo o vanno richieste direttamen-

gli autori. Il contenuto Infomedia e 2004 Infome-

e rilasciato con Licenza Creative Commons 2.5 BY-

ND. Il contenuto Turing Club e 2004 Turing Club

asciato con Licenza Creative Commons 2.5 BY-ND.

pplicano tuttele normedi tuteladeimarchie deisegni

ntivi.

ogni caso ammessa la riproduzione parziale o tota-

ei testi e delle immagini per scopo didattico purche

gano integralmente citati gli autori e la completa

tificazione della testata.

oscritti e foto originali, anche se non pubblicati, non

stituiscono.

tenuto pubblicitario inferiore al 45%.

biografia dellautore riportata nellarticolo e sul

www.infomedia.it e di norma quella disponibi-

nella stampa dellarticolo o aggiornata a cu-

dellautore stesso. Per aggiornarla scrivere a

@infomedia.it o farlo in autonomia allindirizzo

//mags.programmers.net/moduli/biografia

http://www.infomedia.it/http://stores.lulu.com/infomediahttp://stores.lulu.com/infomediahttp://stores.lulu.com/infomediahttp://stores.lulu.com/infomediahttp://www.infomedia.it/

8/3/2019 Gestione automatica della memoria dinamica in C e C++

3/7

Computer Programming n.137 - Luglio/Agosto 2004 21

Garbage Collection

La gestione della memoria dinamica una delle pidolci torture alle quali un programmatore C/C++ quotidianamente sottoposto. Progetti software didimensioni non banali richiedono infatti che una

cospicua parte dello sforzo di sviluppo sia dedicata allagestione e al debug di allocazione e deallocazione di memo-ria. Lintroduzione di algoritmi di Garbage Collection (GC),bench considerata al limite delleresia da parte degli svi-luppatori C/C++ pi conservatori, pu in alcuni casi por-tare dei benefici insospettati.

Algoritmi di Garbage CollectionGli algoritmi per la gestione automatica della memoria

dinamica sono in continua evoluzione fin dalla loro primaintroduzione nel linguaggio LISP, nei primi anni 60, adopera del suo inventore John McCarthy. Molti dei lin-guaggi di programmazione pi diffusi si basano su di essi: Java e C# sono gli esempi pi noti, ma la lista includeanche linguaggi meno usati come LISP, Scheme,Smalltalk, ML. Le versioni moderne di questi algoritmiassicurano nella maggior parte dei casi prestazioni di tuttorispetto, paragonabili e spesso superiori a quelle ottenutecon la gestione esplicita della memoria (basata su mal-loc()/free() e gli operatori new/delete).

Obiettivo della GC individuare i blocchi di memoria

allocati e non pi utilizzati e renderli nuovamente disponi-bili per future allocazioni, senza che il programmatoredebba farlo esplicitamente tramite chiamate tipo free() odelete. A questo scopo, esistono fondamentalmente duediversi approcci: il reference countinge il tracciamento dellamemoria. Il primo, gi discusso sulle pagine di CP ([1]), sibasa su un contatore interno a ciascunarea di memoria (odoggetto) per capire quando larea stessa pu essere liberata.Il reference countingsoffre di un problema di inconsistenzapiuttosto fastidioso (caso di riferimenti circolari, si vedaancora [1]) e non in grado di offrire prestazioni eccezio-

nali a causa dellelevato overhead nella gestione del conta-tore (soprattutto nel caso di oggetti con vita breve). Perquesti motivi, tale approccio sempre meno utilizzato neimoderni sistemi di GC, in favore di algoritmi basati sultracciamento della memoria.

Questi ultimi si possono raggruppare in due grandi cate-gorie: quelli a copia e quelli mark & sweep (letteral-mente: marca e spazza via). I primi mantengono due areedi memoria separate per contenere i blocchi allocati dina-micamente dallutente, una sola delle quali in uso in undeterminato istante. Il lavoro dellalgoritmo consiste nel-lanalisi dello spazio di memoria attivo al fine di localizza-re blocchi allocati ma non raggiungibili dal programma.Tali blocchi sono copiati dallo spazio attivo a quello diappoggio, e i ruoli di questi ultimi sono poi scambiati (algo-ritmo di Cheney). In questo modo, lo spazio attivo in undato istante sempre formato da un insieme continuo diblocchi tutti in uso. Ovviamente, il grosso svantaggio chela memoria richiesta al sistema sempre doppia rispetto aquella utilizzata dal programma.

Il funzionamento degli algoritmi mark & sweep concet-tualmente suddiviso in due fasi: la prima fase (detection)prevede lanalisi dello spazio di memoria dinamico perlocalizzare i blocchi allocati e raggiungibili da programma.Tali blocchi vengono marcati ma non spostati. Durante

la seconda fase (collection), invece, gli indirizzi dei blocchiprecedentemente non marcati sono inseriti tra quelli di-sponibili, tipicamente organizzati in liste omogenee perdimensione del blocco. Il vantaggio degli algoritmi appar-tenenti a questa famiglia che la loro azione facilmentescomponibile in passi successivi (GC incrementale),consentendo una distribuzione omogenea nel tempo delcarico di lavoro dovuto alla memoria sulla CPU.

Esistono infine varianti ibride di GC che combinanocaratteristiche degli algoritmi citati fino a questo momen-to, come per esempio gli algoritmi mark & compact (chespostano le aree di memoria utilizzate per renderle semprecontigue).

Un discorso a parte merita la fase di detection, durante la

quale il sistema di GC deve decidere se un dato blocco dimemoria in uso oppure no. Normalmente questo fattoanalizzando, in un dato istante, linsieme delle variabiliaccessibili dal programma nel punto in cui si trova lesecu-zione (chiamato root set): tale insieme determinato dallu-

Gestione automatica

della memoria dinamicain C e C++La Garbage Collection non un privilegio riservato ai soli programmatori Java e C#:

grazie alla libreria di Hans Boehm possibile dotare i propri programmi C e C++di questo comodo strumento. Ma i programmatori C/C++ di lunga data ne saranno entusiasti?

di Gianluca Insolvibile

Gianluca Insolvibile

laureato in Ingegneria delle Telecomunicazioni. Si occupa di net-working su reti TCP/IP e ATM e di video digitale presso il CentroMETA del Consorzio Pisa Ricerche.

insolvibile@infomedia.it

8/3/2019 Gestione automatica della memoria dinamica in C e C++

4/7

FOCUS

22 Computer Programming n. 137 - Luglio/Agosto 2004

nione delle variabili globali, di quelle locali automatiche,dal contenuto dei registri della CPU e dal contenuto di tuttele aree di memoria puntate da queste variabili. Pi precisa-mente, nel caso di linguaggi di programmazione stronglytyped, lambiente run-time in grado di determinare il tipo diun oggetto dato il suo puntatore; facile a questo punto

sapere se loggetto contiene a sua volta puntatori e prosegui-re la scansione. Diversamente, come avviene per C e C++, impossibile determinare la struttura di unarea di memoriadato il puntatore allarea stessa: in questo caso la scansionedeve riguardare lintera area, con le immaginabili ricadute intermini di prestazioni. La necessit di impiegare la GC conlinguaggi weakly typed come il C ha portato alla definizionedi algoritmi conservativi, nei quali cio il sistema di GCtenta di stimare in modo euristico se un dato intero sia unpuntatore oppure no. Per quanto le stime siano generalmen-

te molto affidabili, tuttavia possibile che, in seguito a unerrore, blocchi di memoria non usati non vengano liberati o,peggio, che blocchi di memoria in uso siano erroneamenteconsiderati disponibili.

Citiamo infine la variante generazionale degli algorit-mi mark & sweep, che concentra la fase di detection sugli

oggetti di pi recente allocazione, sulla base della conside-razione (sperimentalmente verificata) che gli oggetti dina-mici hanno mediamente vita molto breve. In questo modo,il rapporto tra memoria liberata e memoria analizzata puassumere valori sufficientemente elevati da ammortizzareloverhead associato alla GC.

Vantaggi e svantaggi della GCLe dispute sulla convenienza o meno della Garbage

Collection sono interminabili, soprattutto se si prospetta li-

LISTATO 1 Esempio duso di GC in C

#include #include #include #include

#include

/* Parametri di simulazione */#define LIST_LENGTH 25000#define WASTE_SIZE 100#define LOOPS 30

typedef struct list {struct list *next;unsigned int key;unsigned char *vaso;

} list_t;

/** Funzioni per la gestione della lista*/void *(*global_alloc)(unsigned int) = NULL;void *(*global_alloc_atomic)(unsigned int) = NULL;void *calloc_wrap(unsigned int size) { return calloc(1, size); }void *gc_calloc_wrap(unsigned int size) { return GC_malloc(size); }

list_t *add_node(list_t *head, unsigned int key) {list_t *newnode;

newnode = global_alloc(sizeof(list_t));if (!newnode) {printf(Memoria esaurita!\n);return NULL;

}newnode->key = key;newnode->next = head;newnode->vaso = global_alloc_atomic(WASTE_SIZE);if (!newnode->vaso) {printf(Memoria esaurita!\n);

return NULL;}

return newnode;}

list_t *create_list(int n) {list_t *head = NULL;int i;

for (i=0; inext;ptr->next = NULL;ptr->vaso = NULL;ptr = next;

}

}

void free_list(list_t *head) {list_t *ptr = head, *next;

while (ptr) {next = ptr->next;free(ptr->vaso);free(ptr);ptr = next;

}}

/** Programma principale*/

int main(int argc, char **argv) {int n;struct timeval start, end, diff;list_t *head;

/* Tradizionale */global_alloc = calloc_wrap;global_alloc_atomic = malloc;printf(malloc/free test:\n);gettimeofday(&start, NULL);for (n=0; n Allocate %d liste (%d elementi di %d byte)

in %4.2f msec\n,LOOPS, LIST_LENGTH, sizeof(list_t) + WASTE_SIZE,(float)diff.tv_sec*1000.0 + (float)diff.tv_usec/1000.0);

/* GC */global_alloc = gc_calloc_wrap;global_alloc_atomic = GC_malloc_atomic;printf(\n\nGarbage collection test: \n);gettimeofday(&start, NULL);for (n=0; n Allocate %d liste (%d elementi di %d byte)

in %4.2f msec\n,LOOPS, LIST_LENGTH, sizeof(list_t) + WASTE_SIZE,(float)diff.tv_sec*1000.0 + (float)diff.tv_usec/1000.0);

}

8/3/2019 Gestione automatica della memoria dinamica in C e C++

5/7

Computer Programming n. 137 - Luglio/Agosto 2004 23

Garbage Collection

potesi di introdurla in programmi scritti con linguaggi tra-dizionalmente di basso livello. Per un programmatoreC/C++, infatti, lidea di lasciare a un sistema automaticouna cosa tanto importante come la gestione della memoriapu sembrare pura follia.

Daltra parte, senzaltro vero che gran parte del tempodedicato al debug di grossi applicativi imputabile a erroriderivanti da una cattiva gestione della memoria dinamica.Giusto per citare alcuni esempi, si considerino i problemiderivanti da memoria non deallocata (memory leak), daaccessi a memoria deallocata prima del tempo oppure datentativi di liberare pi di una volta uno stesso blocco dimemoria. Molto spesso, tali problemi sono di difficile indi-viduazione perch si manifestano in punti del programmadistanti da quelli dove lerrore si effettivamente verifica-to. La GC elimina a priori e in modo definitivo problemidi questo tipo, liberando il programmatore dallonere ditenere traccia della memoria da liberare. Unaltra conside-razione a favore della gestione automatica della memoria la maggiore pulizia nelle interfacce e nel migliore disac-coppiamento tra moduli software distinti, ottenuti elimi-nando a priori tutte quelle clausole di contratto che sta-biliscono responsabilit sulla allocazione e liberazione dellamemoria.

A sfavore della GC una maggiore occupazione dimemoria rispetto al caso di gestione esplicita, dovuta alfatto che i blocchi di memoria non pi utilizzati non sonoliberati immediatamente (anzi, potrebbero anche non esse-re liberati fino alla fine del programma). Nel caso di pro-grammi C++, inoltre, non possibile determinare con pre-cisione il momento in cui sar chiamato il distruttore di unoggetto non pi utilizzato. Altro svantaggio della GC lamaggiore latenza che si sperimenta in talune condizioni

sulle operazioni di allocazione, deleteria per applicazionireal-time (riproduzione audio/video sincronizzata, risposta aeventi esterni, ecc.).

Infine, nonostante questa sembri essere la credenza picomune, non sempre vero che le prestazioni di un pro-

gramma basato su GC siano inferiori a quelle di uno basa-to su gestione esplicita. Al contrario, se le funzioni di allo-cazione sono usate con criterio spesso possibile ottenereprestazioni migliori, a dimostrazione del fatto che anche lefree() (e le delete) del C/C++ hanno un notevole peso.

Purtroppo non possibile stabilire a priori in quali condi-zioni la GC sia effettivamente pi conveniente: la miglio-re strada per appurarlo sperimentare e valutare caso percaso.

La libreria Boehm-Demers-WeiserDotare i propri programmi C/C++ di un meccanismo di

GC possibile e (quasi) indolore, semplicemente linkandouna libreria Open Source ([2]) e usando le apposite fun-zioni di allocazione da essa fornite. Linstallazione dellalibreria non presenta particolari difficolt: sufficiente laconsueta sequenza configure, make e make install.

La libreria Boehm-Demers-Weiser (che chiameremoBDW) si basa su un algoritmo mark & sweep conservativo,generazionale e opzionalmente incrementale. Essa mette adisposizione una funzione di allocazione base (GC_mal-loc()) e alcune sue varianti da usare per facilitare il compi-to del collector: per esempio, GC_malloc_atomic() pu esse-re usata per allocare un blocco di memoria che sicuramen-te non conterr puntatori a tempo di esecuzione (peresempio, un buffer di I/O). Luso di questa funzione doveappropriato aumenta notevolmente le prestazioni, datoche la fase di analisi dellheap (detection) potr prescinderedai valori contenuti nella memoria cos allocata. Inoltre, laGC_malloc() cancella il blocco di memoria allocato (perevitare che esso contenga vecchi valori che potrebberoessere scambiati in seguito per puntatori), analogamente

alla calloc() della libreria C standard; la GC_alloc_atomic()non ha bisogno di farlo proprio perch il blocco allocatosar ignorato in fase di detection. Nel caso di frequente allo-cazione di aree di grandi dimensioni questo rende ancorpi consigliabile luso di questa funzione.

Sono disponibili infine funzioni che consentono diallocare blocchi di memoria dichiarandone al contempola struttura interna, in modo da indicare al GC in qualiposizioni potranno trovarsi eventuali puntatori. Anche inquesto caso possibile ottenere prestazioni migliori,soprattutto se gli oggetti allocati sono voluminosi e con-tengono pochi puntatori (per esempio, grossi nodi di listeo alberi).

Nessuno dei blocchi di memoria allocati, ovviamente, va

liberato esplicitamente. Per disfarsi di un blocco che nonserve pi, infatti, basta perderne il riferimento: questoaccade quando il puntatore relativo esce di scope ( peresempio il caso di puntatore contenuto in una variabileautomatica, alla fine della funzione) oppure quando lo si

Gli algoritmi per la gestioneautomatica della memoria

dinamica sono in continua

evoluzione fin dai primi anni 60

TABELLA 1 Prestazioni ottenute con il Listato 1

Numero Lunghezza Dimensione Tempo impiegato Guadagno GCcicli lista nodo [msec] rispetto a tradizionale

Tradizionale Garbage Coll.30 25000 12 629.55 407.25 35%30 25000 112 679.73 524.52 22%30 25000 1012 864.77 906.12 -4%30 25000 2048 937.73 1416.84 -51%30 25000 2060 939.07 2396.44 -155%30 25000 8192 1049.50 2446.29 -133%

8/3/2019 Gestione automatica della memoria dinamica in C e C++

6/7

24 Computer Programming n. 137 - Luglio/Agosto 2004

FOCUS

ponga a NULL. Sar compito della libreria GC, duranteuna delle successive allocazioni, decidere se effettuare laraccolta della spazzatura o se chiedere ulteriore memoriaal sistema. Questultimo caso, sorprendentemente, si puverificare anche se la quantit di memoria necessariapotrebbe essere ottenuta riciclando quella non usata.

comunque possibile liberare esplicitamente un blocco dimemoria allocato usando la funzione GC_free().Esistono infine funzioni e variabili di controllo come

GC_enable_incremental(), che abilita la modalit incre-mentale, e GC_free_space_divisor, che permette di stabilireun compromesso tra nuova memoria allocata (maggioreoccupazione di RAM) e frequenza delle operazioni di GC(maggiore carico sulla CPU).

possibile inoltre richiedere esplicitamente una rac-colta di tutta la memoria non utilizzata tramite la funzio-ne GC_gcollect(): in molti casi luso di questa funzione sirivela piuttosto conveniente sia per limitare leccessivaespansione dello heap (la chiamata compatta in qualchemodo la memoria utilizzata) che, sorprendentemente, per

migliorare le prestazioni e la latenza dellalgoritmo diallocazione.

Uso della GC in programmi CPer usare la libreria BDW in programmi C sufficiente

includere il file gc.h e usare le chiamate GC al posto diquelle tradizionali. In fase di link, poi, bisogner aggiunge-re le librerie libgc e libdl.

Il Listato 1 mostra un esempio nel quale si alloca ripetu-

tamente una lista di 25.000 nodi, ciascuna formata da12+100 byte. Si noti che sono state usate due diverse fun-zioni di allocazione per il nodo vero e proprio e per la suaarea dati (campo vaso), rispettivamente: calloc() e malloc()nel caso tradizionale, GC_malloc() e GC_alloc_atomic()nel caso di GC. Lo scopo fare un confronto equo tra i duecasi ricordando che, in base a quanto detto nel paragrafoprecedente, le prestazioni di GC_malloc() vanno confron-tate con calloc() e quelle di GC_malloc_atomic() vannoconfrontate con malloc().

Per compilare il programma sufficiente il comando:

gcc Listato1.c -o Listato1 -lgc -ldl

Il tempo di esecuzione del programma, su un Pentium IVa 2.53 Ghz, di circa 680 msec nel caso di malloc()/free() edi 525 msec nel caso di GC, con un guadagno in prestazio-ni del 22% circa. La Tabella 1 mostra i risultati ottenuticambiando la dimensione dei nodi allocati: in questo test,il guadagno offerto dalla GC diminuisce allaumentaredella dimensione dei nodi, fino a diventare una perditaquando larea allocata arriva intorno ai 1.000 byte.

Ovviamente questa prova va presa come esempio e noncome riferimento assoluto: a seconda del reale profilo di usodella memoria di ciascun programma, la convenienza a usarela GC piuttosto che le funzioni tradizionali pu variareanche notevolmente. Oltretutto, il nostro programma nonconsidera altri parametri importanti come la latenza e laframmentazione della memoria. Il valore di questultimoparametro, in particolare, fornisce unutile indicazione diquanta memoria venga richiesta al sistema operativo (heap)rispetto a quella effettivamente impiegata dal programma.Luso di algoritmi di GC porta frequentemente a frammen-tazioni pi elevate di quelle tipiche di una gestione esplici-ta, a causa della deallocazione differita dei blocchi di memo-ria non pi in uso da parte del programma. Di conseguenza,i requisiti in termini di RAM tendono a essere generalmen-te pi elevati, producendo un effetto negativo anche sulleprestazioni del sistema di cache e paginazione.

Linterfaccia C++

Linterfaccia fornita dalla libreria BDW per programmiC++ basata sullereditariet e richiede linclusione delfile gc_cpp.h. Gli oggetti sono distinti in collectable (ciosottoposti alla liberazione automatica) e non, a seconda dicome vengono allocati. In particolare, dati di tipo nativoallocati tramite loperatore new come in

char *vettore = new char[100]

sono considerati non collectable e vanno liberati manual-mente tramite loperatore delete. Essi possono essere alloca-ti in modalit collectable specificando il parametro UseGC,come in

char *vettore = new (UseGC) char[100]

Il tipo di allocazione per le classi determinato derivan-dole da opportune classi base: per ottenere una classe col-lectable occorre derivarla dalla classe predefinita gc:

LISTATO 2 Esempio duso di GC in C++

#include #include

using std::cout;using std::endl;

class MiaClasseGC : public virtual gc {

public:

MiaClasseGC() { constructors++; }~MiaClasseGC() { destructors++; }

static unsigned int constructors;static unsigned int destructors;

};

class MiaClasseGCClean : public virtual gc_cleanup {

public:MiaClasseGCClean() { constructors++; }~MiaClasseGCClean() { destructors++; }

static unsigned int constructors;static unsigned int destructors;

};

unsigned int MiaClasseGC::constructors = 0;unsigned int MiaClasseGC::destructors = 0;unsigned int MiaClasseGCClean::constructors = 0;unsigned int MiaClasseGCClean::destructors = 0;

int main(int argc, char **argv) {

for (int i=0; i

8/3/2019 Gestione automatica della memoria dinamica in C e C++

7/7

Computer Programming n. 137 - Luglio/Agosto 2004 25

Garbage Collection

class MiaClasseGC : public virtual gc {

...

};

In questo caso, lallocazione della classe gestita inmodo automatico ma il distruttore della classe non viene

chiamato quando loggetto viene liberato. Se si vuole chela libreria invochi il distruttore occorre invece derivare laclasse dagc_cleanup:

class MiaClasseGCClean : public virtual gc_cleanup {

...

};

Lesempio presentato nel Listato 2 alloca una serie dioggetti delle due classi senza mantenerne i puntatori, inmodo che essi siano reclamabili dalla GC. Loutput del pro-gramma mostra come il distruttore venga chiamato soloper gli oggetti appartenenti alla seconda classe. interes-sante notare inoltre che non tutti gli oggetti sono stati

deallocati alla fine del ciclo: questo perfettamente lecito,dato che comunque la memoria sar completamente deal-locata al termine del programma. Il corretto funzionamen-to del GC ben visibile dalla dimensione dello heap, chenon supera mai i 256 KB nonostante si siano complessiva-mente allocati oggetti per quasi 50 MB senza mai liberarnenessuno esplicitamente.

ConclusioniLa libreria BDW consente di dotare i propri programmi

C/C++ di una gestione della memoria con GarbageCollection in modo relativamente semplice. Contra-riamente a quanto ci si potrebbe aspettare, i vantaggi nel-luso della GC non si limitano a una maggiore pulizia del

codice e includono in certi casi anche prestazioni migliori.Luso della GC invece assolutamente da evitare quando sidebba avere il controllo puntuale sulle risorse impegnate(memoria e tempo di esecuzione): in casi estremi, benericordarlo, anche le malloc() e free() della libreria C sonoinadeguate ed opportuno ricorrere ad allocatori persona-lizzati.

Nessuna soluzione la migliore in assoluto: sta allespe-rienza del programmatore valutare caso per caso quale siaquella pi conveniente a seconda delle peculiarit delproprio programma. In questo senso, utile non scartarea priori nessuna possibilit e considerare la GC come unadelle diverse alternative a propria disposizione.

BIBLIOGRAFIA & RIFERIMENTI

[1] L. Vandoni La gestione del Garbage Collector, CP 118,Infomedia, Novembre 2002

[2] http://www.hpl.hp.com/personal/Hans_Boehm/gc

Anche lItalia, al pari di molti altri stati europei, presenta unevento di rilievo nazionale sul linguaggio Perl. Si terr infatti, il19 e il 20 Luglio 2004, lItalian Perl Workshop. La sede sceltaper questa prima, storica, edizione Pisa: levento sar infattiospitato nei locali del Polo Fibonacci dellUniversit di Pisa.Lobiettivo principale del workshop quello di fornire unoc-casione dincontro per chi programma in Perl oppure inqualche modo interessato a tale linguaggio. Esso si rivolge siaalle realt professionali che a quelle amatoriali, cio a chiun-

que sia interessato allutilizzo di Perl, al fine di favorire loscambio di esperienze e la creazione di una rete di relazionia livello nazionale.Le due giornate saranno caratterizzate da interventi tecnici,cio da talk che potranno assumere diversi formati. Vi saran-no infatti degli interventi lunghi, della durata di una o pi ore,

sugli argomenti pi complessi, e degliinterventi un po pi brevi, che di fattocostituiranno la maggior parte dei contri-buti al workshop. Sar inoltre dedicatoun certo spazio ai cosiddetti interventilampo, finalizzati a far conoscere al pub-blico unidea per un progetto, un truccooppure unopinione. Sar infine organiz-

zato uno spazio in cui ciascun parteci-pante potr esporre il proprio poster, edavere a disposizione una postazione uti-lizzabile per spiegare il proprio lavoro erispondere alle domande degli interes-

sati. Gli argomenti trattati saranno molteplici: si spazier dalweb alle interfacce utente, alle ottimizzazioni di Perl fino alfuturo del linguaggio, che porta il nome di Parrot/Perl 6. Siparler, tra le altre cose, di programmazione OOP, di databa-se, di SOAP, e di integrazione di Perl con altri ambienti di svi-luppo. Tutti i talk saranno in lingua italiana, tranne quelli degli

ospiti stranieri, per i quali verr comunque fornito del mate-riale in italiano. Ospite deccezione sar il britannico LeonBrocard, che curer un approfondimento dello sviluppo del-linterprete perl. Sponsor dellevento saranno Activestate, UlisS.r.l., K Solutions, PC Express S.r.l.Ulteriori informazioni allindirizzo http://www.perlworkshop.it

In breve

Italian Perl Workshop 2004