From: Simone Piccardi Date: Wed, 23 Oct 2002 18:22:02 +0000 (+0000) Subject: Aggiunto contributo di Daniele Masini sulla gestione della memoria nei X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=3f0b7dc79bb38d391505385754c9e3c222b6c86d;p=gapil.git Aggiunto contributo di Daniele Masini sulla gestione della memoria nei vari linguaggi. --- diff --git a/ChangeLog b/ChangeLog index 98ce465..2d63dd8 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2002-10-23 Simone Piccardi + + * process.tex: Aggiunta nota di Daniele Masini sulle differenze + fra i vari linguaggi riguardo l'allocazione della memoria. + 2002-10-22 Simone Piccardi * process.tex: Correzione di un typo, segnalato da zaker. diff --git a/process.tex b/process.tex index 9983e82..67cb4f5 100644 --- a/process.tex +++ b/process.tex @@ -532,18 +532,18 @@ variabile \macro{MALLOC\_CHECK\_} che quando viene definita mette in uso una versione meno efficiente delle funzioni suddette, che però è più tollerante nei confronti di piccoli errori come quello di chiamate doppie a \func{free}. In particolare: -\begin{itemize*} +\begin{itemize} \item se la variabile è posta a zero gli errori vengono ignorati. \item se è posta ad 1 viene stampato un avviso sullo \textit{standard error} (vedi \secref{sec:file_std_stream}). \item se è posta a 2 viene chiamata \func{abort}, che in genere causa l'immediata conclusione del programma. -\end{itemize*} +\end{itemize} Il problema più comune e più difficile da risolvere che si incontra con le routine di allocazione è quando non viene opportunamente liberata la memoria non più utilizzata, quello che in inglese viene chiamato \textit{memory-leak}, -cioè \textsl{perdita di memoria}. +cioè una \textsl{perdita di memoria}. Un caso tipico che illustra il problema è quello in cui in una subroutine si alloca della memoria per uso locale senza liberarla prima di uscire. La @@ -558,22 +558,54 @@ essere in una sezione del codice che non ha alcuna relazione con la subroutine che contiene l'errore. Per questo motivo è sempre molto difficile trovare un \textit{memory leak}. -Per ovviare a questi problemi l'implementazione delle routine di allocazione -delle \acr{glibc} mette a disposizione una serie di funzionalità che -permettono di tracciare le allocazioni e le disallocazione, e definisce anche -una serie di possibili \textit{hook} (\textsl{ganci}) che permettono di -sostituire alle funzioni di libreria una propria versione (che può essere più -o meno specializzata per il debugging). +In C e C++ il problema è particolarmente sentito. In C++, per mezzo della +programmazione ad oggetti, il problema dei \textit{memory leak} è notevolmente +ridimensionato attraverso l'uso accurato di appositi oggetti come gli +\textit{smartpointers}. Questo però va a scapito delle performance +dell'applicazione in esecuzione. + +In altri linguaggi come il java e recentemente il C\# il problema non si pone +nemmeno perché la gestione della memoria viene fatta totalmente in maniera +automatica, ovvero il programmatore non deve minimamente preoccuparsi di +liberare la memoria allocata precedentemente quando non serve più, poiché il +framework gestisce automaticamente la cosiddetta \textit{garbage collection}. +In tal caso, attraverso meccanismi simili a quelli del \textit{reference + counting}, quando una zona di memoria precedentemente allocata non è più +riferita da nessuna parte del codice in esecuzione, può essere deallocata +automaticamente in qualunque momento dall'infrastruttura. + +Anche questo va a scapito delle performance dell'applicazione in esecuzione +(inoltre le applicazioni sviluppate con tali linguaggi di solito non sono +eseguibili compilati, come avviene invece per il C ed il C++, ed è necessaria +la presenza di una infrastruttura per la loro interpretazione e pertanto hanno +di per sé delle performance più scadenti rispetto alle stesse applicazioni +compilate direttamente). Questo comporta però il problema della non +predicibilità del momento in cui viene deallocata la memoria precedentemente +allocata da un oggetto. + +Per limitare l'impatto di questi problemi, e semplificare la ricerca di +eventuali errori, l'implementazione delle routine di allocazione delle +\acr{glibc} mette a disposizione una serie di funzionalità che permettono di +tracciare le allocazioni e le disallocazione, e definisce anche una serie di +possibili \textit{hook} (\textsl{ganci}) che permettono di sostituire alle +funzioni di libreria una propria versione (che può essere più o meno +specializzata per il debugging). Esistono varie librerie che forniscono dei +sostituti opportuni delle routine di allocazione in grado, senza neanche +ricompilare il programma,\footnote{esempi sono \textit{Dmalloc} + \href{http://dmalloc.com/}{http://dmalloc.com/} di Gray Watson ed + \textit{Electric Fence} di Bruce Perens.} di eseguire diagnostiche anche +molto complesse riguardo l'allocazione della memoria. + \subsection{La funzione \func{alloca}} \label{sec:proc_mem_alloca} Una possibile alternativa all'uso di \func{malloc}, che non soffre dei -problemi di memory leak descritti in precedenza, è la funzione \func{alloca}, -che invece di allocare la memoria nello heap usa il segmento di stack della -funzione corrente. La sintassi è identica a quella di \func{malloc}, il suo -prototipo è: +problemi di \textit{memory leak} descritti in precedenza, è la funzione +\func{alloca}, che invece di allocare la memoria nello heap usa il segmento di +stack della funzione corrente. La sintassi è identica a quella di +\func{malloc}, il suo prototipo è: \begin{prototype}{stdlib.h}{void *alloca(size\_t size)} Alloca \var{size} byte nel segmento di stack della funzione chiamante. La memoria non viene inizializzata. diff --git a/ringraziamenti.tex b/ringraziamenti.tex index a241526..779eccc 100644 --- a/ringraziamenti.tex +++ b/ringraziamenti.tex @@ -8,8 +8,9 @@ GaPiL. In ordine rigorosamente alfabetico desidero citare: \item[\textbf{Alessio Frusciante}] per l'apprezzamento, le molteplici correzioni ed i suggerimenti per rendere più chiara l'esposizione. \item[\textbf{Daniele Masini}] per la rilettura puntuale, le innumerevoli - correzioni, i consigli sull'esposizione ed il contributo relativo alle - calling convention dei linguaggi. + correzioni, i consigli sull'esposizione ed i contributi relativi alle + calling convention dei linguaggi e al confronto delle diverse tecniche di + gestione della memoria. \end{description} %%% Local Variables: