Context Navigation

-              rf53afafb
+              r3a038fa
 \chapter{Introduction}
-\section{Introduction}
 % Shared-memory multi-processor computers are ubiquitous and important for improving application performance.
 …
 % Therefore, providing high-performance, scalable memory-management is important for virtually all shared-memory multi-threaded programs.
+\vspace*{-23pt}
 Memory management takes a sequence of program generated allocation/deallocation requests and attempts to satisfy them within a fixed-sized block of memory while minimizing the total amount of memory used.
 A general-purpose dynamic-allocation algorithm cannot anticipate future allocation requests so its output is rarely optimal.
 …
 \subsection{Memory Structure}
+\section{Memory Structure}
 \label{s:MemoryStructure}
 …
 Dynamic code/data memory is managed by the dynamic loader for libraries loaded at runtime, which is complex especially in a multi-threaded program~\cite{Huang06}.
 However, changes to the dynamic code/data space are typically infrequent, many occurring at program startup, and are largely outside of a program's control.
 Stack memory is managed by the program call-mechanism using simple LIFO management, which works well for sequential programs.
+Stack memory is managed by the program call-mechanism using a simple LIFO technique, which works well for sequential programs.
 For multi-threaded programs (and coroutines), a new stack is created for each thread;
 these thread stacks are commonly created in dynamic-allocation memory.
 …
 \subsection{Dynamic Memory-Management}
+\section{Dynamic Memory-Management}
 \label{s:DynamicMemoryManagement}
 Modern programming languages manage dynamic-allocation memory in different ways.
 Some languages, such as Lisp~\cite{CommonLisp}, Java~\cite{Java}, Go~\cite{Go}, Haskell~\cite{Haskell}, provide explicit allocation but \emph{implicit} deallocation of data through garbage collection~\cite{Wilson92}.
+Some languages, such as Lisp~\cite{CommonLisp}, Java~\cite{Java}, Haskell~\cite{Haskell}, Go~\cite{Go}, provide explicit allocation but \emph{implicit} deallocation of data through garbage collection~\cite{Wilson92}.
 In general, garbage collection supports memory compaction, where dynamic (live) data is moved during runtime to better utilize space.
 However, moving data requires finding pointers to it and updating them to reflect new data locations.
 …
 However, high-performance memory-allocators for kernel and user multi-threaded programs are still being designed and improved.
 For this reason, several alternative general-purpose allocators have been written for C/\CC with the goal of scaling in a multi-threaded program~\cite{Berger00,mtmalloc,streamflow,tcmalloc}.
 This work examines the design of high-performance allocators for use by kernel and user multi-threaded applications written in C/\CC.
 \subsection{Contributions}
+This thesis examines the design of high-performance allocators for use by kernel and user multi-threaded applications written in C/\CC.
+\section{Contributions}
 \label{s:Contributions}
 This work provides the following contributions in the area of concurrent dynamic allocation:
+\begin{enumerate}
+\item
+Implementation of a new stand-lone concurrent memory allocator ($\approx$1,200 lines of code) for C/\CC programs using kernel threads (1:1 threading), and specialized versions of the allocator for programming languages \uC and \CFA using user-level threads running over multiple kernel threads (M:N threading).
+\item
+Adopt the return of @nullptr@ for a zero-sized allocation, rather than an actual memory address, both of which can be passed to @free@.
+Most allocators use @nullptr@ to indicate an allocation failure, such as full memory;
+hence the need to return an alternate value for a zero-sized allocation.
+The alternative is to abort the program on allocation failure.
+In theory, notifying the programmer of a failure allows recovery;
+in practice, it is almost impossible to gracefully recover from allocation failure, especially full memory, so adopting the cheaper return @nullptr@ for a zero-sized allocation is chosen.
+\item
+Extended the standard C heap functionality by preserving with each allocation its original request size versus the amount allocated due to bucketing, if an allocation is zero fill, and the allocation alignment.
+\begin{enumerate}[leftmargin=*]
+\item
+Implementation of a new stand-lone concurrent low-latency memory-allocator ($\approx$1,200 lines of code) for C/\CC programs using kernel threads (1:1 threading), and specialized versions of the allocator for programming languages \uC and \CFA using user-level threads running over multiple kernel threads (M:N threading).
+\item
+Adopt returning of @nullptr@ for a zero-sized allocation, rather than an actual memory address, both of which can be passed to @free@.
+\item
+Extended the standard C heap functionality by preserving with each allocation its original request size versus the amount allocated, if an allocation is zero fill, and the allocation alignment.
 \item
 …
 \item
+Provide complete and fast allocation statistics to help understand program behaviour:
+Provide mostly contention-free allocation and free operations via a heap-per-kernel-thread implementation.
+\item
+Provide complete, fast, and contention-free allocation statistics to help understand program behaviour:
 \begin{itemize}
 \item
 …
 \item
+Provide mostly contention-free allocation and free operations via a heap-per-kernel-thread implementation.
+\item
+Provide extensive contention-free runtime checks to valid allocation operations and identify the amount of unfreed storage at program termination.
+Provide extensive runtime checks to valid allocation operations and identify the amount of unfreed storage at program termination.
 \item

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset 3a038fa for doc/theses/mubeen_zulfiqar_MMath/intro.tex

Legend:

doc/theses/mubeen_zulfiqar_MMath/intro.tex

Download in other formats: