Aggiunto contributo di Daniele Masini sulla gestione della memoria nei

vari linguaggi.

diff --git a/ChangeLog b/ChangeLog
index 98ce465ec45468c7abaff3bb0dc218bb07322624..2d63dd86d5f541a20100ab6a8ca5582c31fb4866 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2002-10-23  Simone Piccardi  <piccardi@firenze.linux.it>
+
+       * process.tex: Aggiunta nota di Daniele Masini sulle differenze
+       fra i vari linguaggi riguardo l'allocazione della memoria. 
+

 2002-10-22  Simone Piccardi  <piccardi@firenze.linux.it>
 
        * process.tex: Correzione di un typo, segnalato da zaker.
 2002-10-22  Simone Piccardi  <piccardi@firenze.linux.it>
 
        * process.tex: Correzione di un typo, segnalato da zaker.

diff --git a/process.tex b/process.tex
index 9983e8230b06073026adc9eb24f122b9a7a5f11b..67cb4f5ccf1da431546545983e53a4624880529f 100644 (file)
--- 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:
 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.
 \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},
 
 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
 
 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}.
 
 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
 
 
 \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.
 \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 a2415264035ed9c05ae4913d60b7411d74f89d02..779eccccab95ccc9b28739e030b3acb12aa88096 100644 (file)
--- 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
 \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: 
 \end{description}
 
 %%% Local Variables: