Changeset e5d9274 for doc/theses/mubeen_zulfiqar_MMath

doc/theses/mubeen_zulfiqar_MMath/allocator.tex

-              r015925a
+              re5d9274
 llheap's design was reviewed and changed multiple times throughout the thesis.
 Some of the rejected designs are discussed because they show the path to the final design (see discussion in \VRef{s:MultipleHeaps}).
 Note, a few simples tests for a design choice were compared with the current best allocators to determine the viability of a design.
+Note, a few simple tests for a design choice were compared with the current best allocators to determine the viability of a design.
 …
 These designs look at the allocation/free \newterm{fastpath}, \ie when an allocation can immediately return free storage or returned storage is not coalesced.
 \paragraph{T:1 model}
 \VRef[Figure]{f:T1SharedBuckets} shows one heap accessed by multiple kernel threads (KTs) using a bucket array, where smaller bucket sizes are N-shared across KTs.
 This design leverages the fact that 95\% of allocation requests are less than 1024 bytes and there are only 3--5 different request sizes.
+\VRef[Figure]{f:T1SharedBuckets} shows one heap accessed by multiple kernel threads (KTs) using a bucket array, where smaller bucket sizes are shared among N KTs.
+This design leverages the fact that usually the allocation requests are less than 1024 bytes and there are only a few different request sizes.
 When KTs $\le$ N, the common bucket sizes are uncontented;
 when KTs $>$ N, the free buckets are contented and latency increases significantly.
 …
 \paragraph{T:H model}
 \VRef[Figure]{f:THSharedHeaps} shows a fixed number of heaps (N), each a local free pool, where the heaps are sharded across the KTs.
+\VRef[Figure]{f:THSharedHeaps} shows a fixed number of heaps (N), each a local free pool, where the heaps are sharded (distributed) across the KTs.
 A KT can point directly to its assigned heap or indirectly through the corresponding heap bucket.
 When KT $\le$ N, the heaps are uncontented;
+When KT $\le$ N, the heaps might be uncontented;
 when KTs $>$ N, the heaps are contented.
 In all cases, a KT must acquire/release a lock, contented or uncontented along the fast allocation path because a heap is shared.
 By adjusting N upwards, this approach reduces contention but increases storage (time versus space);
+By increasing N, this approach reduces contention but increases storage (time versus space);
 however, picking N is workload specific.
 …
 Need to prevent preemption during a dynamic memory operation because of the \newterm{serially-reusable problem}.
 \begin{quote}
 A sequence of code that is guaranteed to run to completion before being invoked to accept another input is called serially-reusable code.~\cite{SeriallyReusable}
+A sequence of code that is guaranteed to run to completion before being invoked to accept another input is called serially-reusable code.~\cite{SeriallyReusable}\label{p:SeriallyReusable}
 \end{quote}
 If a KT is preempted during an allocation operation, the operating system can schedule another KT on the same CPU, which can begin an allocation operation before the previous operation associated with this CPU has completed, invalidating heap correctness.
 …
 (See \VRef[Figure]{f:THSharedHeaps} but with a heap bucket per KT and no bucket or local-pool lock.)
 Hence, immediately after a KT starts, its heap is created and just before a KT terminates, its heap is (logically) deleted.
 Heaps are uncontended for a KTs memory operations to its heap (modulo operations on the global pool and ownership).
+Heaps are uncontended for a KTs memory operations as every KT has its own thread-local heap, modulo operations on the global pool and ownership.
 Problems:
 \begin{itemize}
 \item
 Need to know when a KT is starts/terminates to create/delete its heap.
+Need to know when a KT starts/terminates to create/delete its heap.
 \noindent
 …
 \noindent
 In many concurrent applications, good performance is achieved with the number of KTs proportional to the number of CPUs.
 Since the number of CPUs is relatively small, >~1024, and a heap relatively small, $\approx$10K bytes (not including any associated freed storage), the worst-case external fragmentation is still small compared to the RAM available on large servers with many CPUs.
+Since the number of CPUs is relatively small, and a heap is also relatively small, $\approx$10K bytes (not including any associated freed storage), the worst-case external fragmentation is still small compared to the RAM available on large servers with many CPUs.
 \item
 There is the same serially-reusable problem with UTs migrating across KTs.
 …
 \noindent
 The conclusion from this design exercise is: any atomic fence, atomic instruction (lock free), or lock along the allocation fastpath produces significant slowdown.
 For the T:1 and T:H models, locking must exist along the allocation fastpath because the buckets or heaps maybe shared by multiple threads, even when KTs $\le$ N.
+For the T:1 and T:H models, locking must exist along the allocation fastpath because the buckets or heaps might be shared by multiple threads, even when KTs $\le$ N.
 For the T:H=CPU and 1:1 models, locking is eliminated along the allocation fastpath.
 However, T:H=CPU has poor operating-system support to determine the CPU id (heap id) and prevent the serially-reusable problem for KTs.
 More operating system support is required to make this model viable, but there is still the serially-reusable problem with user-level threading.
 Leaving the 1:1 model with no atomic actions along the fastpath and no special operating-system support required.
+So the 1:1 model had no atomic actions along the fastpath and no special operating-system support requirements.
 The 1:1 model still has the serially-reusable problem with user-level threading, which is addressed in \VRef{s:UserlevelThreadingSupport}, and the greatest potential for heap blowup for certain allocation patterns.
 …
 Ideally latency is $O(1)$ with a small constant.
 To obtain $O(1)$ internal latency means no searching on the allocation fastpath, largely prohibits coalescing, which leads to external fragmentation.
+To obtain $O(1)$ internal latency means no searching on the allocation fastpath and largely prohibits coalescing, which leads to external fragmentation.
 The mitigating factor is that most programs have well behaved allocation patterns, where the majority of allocation operations can be $O(1)$, and heap blowup does not occur without coalescing (although the allocation footprint may be slightly larger).
 …
 llheap starts by creating an array of $N$ global heaps from storage obtained using @mmap@, where $N$ is the number of computer cores, that persists for program duration.
 There is a global bump-pointer to the next free heap in the array.
 When this array is exhausted, another array is allocated.
 There is a global top pointer for a heap intrusive link to chain free heaps from terminated threads.
 When statistics are turned on, there is a global top pointer for a heap intrusive link to chain \emph{all} the heaps, which is traversed to accumulate statistics counters across heaps using @malloc_stats@.
+When this array is exhausted, another array of heaps is allocated.
+There is a global top pointer for a intrusive linked-list to chain free heaps from terminated threads.
+When statistics are turned on, there is a global top pointer for a intrusive linked-list to chain \emph{all} the heaps, which is traversed to accumulate statistics counters across heaps using @malloc_stats@.
 When a KT starts, a heap is allocated from the current array for exclusive use by the KT.
 When a KT terminates, its heap is chained onto the heap free-list for reuse by a new KT, which prevents unbounded growth of heaps.
 The free heaps is a stack so hot storage is reused first.
 Preserving all heaps created during the program lifetime, solves the storage lifetime problem, when ownership is used.
+When a KT terminates, its heap is chained onto the heap free-list for reuse by a new KT, which prevents unbounded growth of number of heaps.
+The free heaps are stored on stack so hot storage is reused first.
+Preserving all heaps, created during the program lifetime, solves the storage lifetime problem when ownership is used.
 This approach wastes storage if a large number of KTs are created/terminated at program start and then the program continues sequentially.
 llheap can be configured with object ownership, where an object is freed to the heap from which it is allocated, or object no-ownership, where an object is freed to the KT's current heap.
 Each heap uses segregated free-buckets that have free objects distributed across 91 different sizes from 16 to 4M.
+All objects in a bucket are of the same size.
 The number of buckets used is determined dynamically depending on the crossover point from @sbrk@ to @mmap@ allocation using @mallopt( M_MMAP_THRESHOLD )@, \ie small objects managed by the program and large objects managed by the operating system.
 Each free bucket of a specific size has the following two lists:
 …
 Quantizing is performed using a binary search over the ordered bucket array.
 An optional optimization is fast lookup $O(1)$ for sizes < 64K from a 64K array of type @char@, where each element has an index to the corresponding bucket.
+(Type @char@ restricts the number of bucket sizes to 256.)
+The @char@ type restricts the number of bucket sizes to 256.
 For $S$ > 64K, a binary search is used.
 Then, the allocation storage is obtained from the following locations (in order), with increasing latency.
 …
 Then the corresponding bucket of the owner thread is computed for the deallocating thread, and the allocation is pushed onto the deallocating thread's bucket.
 Finally, the llheap design funnels \label{p:FunnelRoutine} all allocation/deallocation operations through routines @malloc@/@free@, which are the only routines to directly access and manage the internal data structures of the heap.
+Finally, the llheap design funnels \label{p:FunnelRoutine} all allocation/deallocation operations through the @malloc@ and @free@ routines, which are the only routines to directly access and manage the internal data structures of the heap.
 Other allocation operations, \eg @calloc@, @memalign@, and @realloc@, are composed of calls to @malloc@ and possibly @free@, and may manipulate header information after storage is allocated.
 This design simplifies heap-management code during development and maintenance.
 …
 \subsection{Alignment}
 All dynamic memory allocations must have a minimum storage alignment for the contained object(s).
+Most dynamic memory allocations have a minimum storage alignment for the contained object(s).
 Often the minimum memory alignment, M, is the bus width (32 or 64-bit) or the largest register (double, long double) or largest atomic instruction (DCAS) or vector data (MMMX).
 In general, the minimum storage alignment is 8/16-byte boundary on 32/64-bit computers.
 For consistency, the object header is normally aligned at this same boundary.
 Larger alignments must be a power of 2, such page alignment (4/8K).
+Larger alignments must be a power of 2, such as page alignment (4/8K).
 Any alignment request, N, $\le$ the minimum alignment is handled as a normal allocation with minimal alignment.
 …
 \end{center}
 The storage between @E@ and @H@ is chained onto the appropriate free list for future allocations.
 This approach is also valid within any sufficiently large free block, where @E@ is the start of the free block, and any unused storage before @H@ or after the allocated object becomes free storage.
+The same approach is used for sufficiently large free blocks, where @E@ is the start of the free block, and any unused storage before @H@ or after the allocated object becomes free storage.
 In this approach, the aligned address @A@ is the same as the allocated storage address @P@, \ie @P@ $=$ @A@ for all allocation routines, which simplifies deallocation.
 However, if there are a large number of aligned requests, this approach leads to memory fragmentation from the small free areas around the aligned object.
 …
 Finally, this approach is incompatible with allocator designs that funnel allocation requests through @malloc@ as it directly manipulates management information within the allocator to optimize the space/time of a request.
 Instead, llheap alignment is accomplished by making a \emph{pessimistically} allocation request for sufficient storage to ensure that \emph{both} the alignment and size request are satisfied, \eg:
+Instead, llheap alignment is accomplished by making a \emph{pessimistic} allocation request for sufficient storage to ensure that \emph{both} the alignment and size request are satisfied, \eg:
 \begin{center}
 \input{Alignment2}
 …
 \input{Alignment2Impl}
 \end{center}
 Since @malloc@ has a minimum alignment of @M@, @P@ $\neq$ @A@ only holds for alignments of @M@ or greater.
+Since @malloc@ has a minimum alignment of @M@, @P@ $\neq$ @A@ only holds for alignments greater than @M@.
 When @P@ $\neq$ @A@, the minimum distance between @P@ and @A@ is @M@ bytes, due to the pessimistic storage-allocation.
 Therefore, there is always room for an @M@-byte fake header before @A@.
 …
 \label{s:ReallocStickyProperties}
 Allocation routine @realloc@ provides a memory-management pattern for shrinking/enlarging an existing allocation, while maintaining some or all of the object data, rather than performing the following steps manually.
+The allocation routine @realloc@ provides a memory-management pattern for shrinking/enlarging an existing allocation, while maintaining some or all of the object data, rather than performing the following steps manually.
 \begin{flushleft}
 \begin{tabular}{ll}
 …
 The realloc pattern leverages available storage at the end of an allocation due to bucket sizes, possibly eliminating a new allocation and copying.
 This pattern is not used enough to reduce storage management costs.
 In fact, if @oaddr@ is @nullptr@, @realloc@ does a @malloc@, so even the initial @malloc@ can be a @realloc@ for consistency in the pattern.
+In fact, if @oaddr@ is @nullptr@, @realloc@ does a @malloc@, so even the initial @malloc@ can be a @realloc@ for consistency in the allocation pattern.
 The hidden problem for this pattern is the effect of zero fill and alignment with respect to reallocation.
 Are these properties transient or persistent (``sticky'')?
 For example, when memory is initially allocated by @calloc@ or @memalign@ with zero fill or alignment properties, respectively, what happens when those allocations are given to @realloc@ to change size.
 That is, if @realloc@ logically extends storage into unused bucket space or allocates new storage to satisfy a size change, are initial allocation properties preserve?
+For example, when memory is initially allocated by @calloc@ or @memalign@ with zero fill or alignment properties, respectively, what happens when those allocations are given to @realloc@ to change size?
+That is, if @realloc@ logically extends storage into unused bucket space or allocates new storage to satisfy a size change, are initial allocation properties preserved?
 Currently, allocation properties are not preserved, so subsequent use of @realloc@ storage may cause inefficient execution or errors due to lack of zero fill or alignment.
 This silent problem is unintuitive to programmers and difficult to locate because it is transient.
 …
 To preserve allocation properties requires storing additional information with an allocation,
 The only available location is the header, where \VRef[Figure]{f:llheapNormalHeader} shows the llheap storage layout.
+The best available option is the header, where \VRef[Figure]{f:llheapNormalHeader} shows the llheap storage layout.
 The header has two data field sized appropriately for 32/64-bit alignment requirements.
 The first field is a union of three values:
 …
 \end{description}
 The second field remembers the request size versus the allocation (bucket) size, \eg request 42 bytes which is rounded up to 64 bytes.
 Since programmers think in request sizes rather than allocation sizes, the request size allows better generation of statistics or errors.
+Since programmers think in request sizes rather than allocation sizes, the request size allows better generation of statistics or errors and also helps in memory management.
 \begin{figure}
 …
 \end{figure}
 The low-order 3-bits of the first field are \emph{unused} for any stored values, whereas the second field may use all of its bits.
+The low-order 3-bits of the first field are \emph{unused} for any stored values as these values are 16-byte aligned by default, whereas the second field may use all of its bits.
 The 3 unused bits are used to represent mapped allocation, zero filled, and alignment, respectively.
 Note, the alignment bit is not used in the normal header and the zero-filled/mapped bits are not used in the fake header.
 …
 If no bits are on, it implies a basic allocation, which is handled quickly;
 otherwise, the bits are analysed and appropriate actions are taken for the complex cases.
 Since most allocations are basic, this implementation results in a significant performance gain along the allocation and free fastpath.
+Since most allocations are basic, they will take significantly less time as the memory operations will be done along the allocation and free fastpath.
 …
 To locate all statistic counters, heaps are linked together in statistics mode, and this list is locked and traversed to sum all counters across heaps.
 Note, the list is locked to prevent errors traversing an active list;
 the statistics counters are not locked and can flicker during accumulation, which is not an issue with atomic read/write.
+the statistics counters are not locked and can flicker during accumulation.
 \VRef[Figure]{f:StatiticsOutput} shows an example of statistics output, which covers all allocation operations and information about deallocating storage not owned by a thread.
 No other memory allocator studied provides as comprehensive statistical information.
 Finally, these statistics were invaluable during the development of this thesis for debugging and verifying correctness, and hence, should be equally valuable to application developers.
+Finally, these statistics were invaluable during the development of this thesis for debugging and verifying correctness and should be equally valuable to application developers.
 \begin{figure}
 …
 Nevertheless, the checks detect many allocation problems.
 There is an unfortunate problem in detecting unfreed storage because some library routines assume their allocations have life-time duration, and hence, do not free their storage.
 For example, @printf@ allocates a 1024 buffer on first call and never deletes this buffer.
+For example, @printf@ allocates a 1024-byte buffer on the first call and never deletes this buffer.
 To prevent a false positive for unfreed storage, it is possible to specify an amount of storage that is never freed (see @malloc_unfreed@ \VPageref{p:malloc_unfreed}), and it is subtracted from the total allocate/free difference.
 Determining the amount of never-freed storage is annoying, but once done, any warnings of unfreed storage are application related.
 Tests indicate only a 30\% performance increase when statistics \emph{and} debugging are enabled, and the latency cost for accumulating statistic is mitigated by limited calls, often only one at the end of the program.
+Tests indicate only a 30\% performance decrease when statistics \emph{and} debugging are enabled, and the latency cost for accumulating statistic is mitigated by limited calls, often only one at the end of the program.
 …
 \label{s:UserlevelThreadingSupport}
 The serially-reusable problem (see \VRef{s:AllocationFastpath}) occurs for kernel threads in the ``T:H model, H = number of CPUs'' model and for user threads in the ``1:1'' model, where llheap uses the ``1:1'' model.
 The solution is to prevent interrupts that can result in CPU or KT change during operations that are logically critical sections.
+The serially-reusable problem (see \VPageref{p:SeriallyReusable}) occurs for kernel threads in the ``T:H model, H = number of CPUs'' model and for user threads in the ``1:1'' model, where llheap uses the ``1:1'' model.
+The solution is to prevent interrupts that can result in a CPU or KT change during operations that are logically critical sections such as starting a memory operation on one KT and completing it on another.
 Locking these critical sections negates any attempt for a quick fastpath and results in high contention.
 For user-level threading, the serially-reusable problem appears with time slicing for preemptable scheduling, as the signal handler context switches to another user-level thread.
 Without time slicing, a user thread performing a long computation can prevent execution (starve) other threads.
 To prevent starvation for an allocation-active thread, \ie the time slice always triggers in an allocation critical-section for one thread, a thread-local \newterm{rollforward} flag is set in the signal handler when it aborts a time slice.
+Without time slicing, a user thread performing a long computation can prevent the execution of (starve) other threads.
+To prevent starvation for a memory-allocation-intensive thread, \ie the time slice always triggers in an allocation critical-section for one thread so the thread never gets time sliced, a thread-local \newterm{rollforward} flag is set in the signal handler when it aborts a time slice.
 The rollforward flag is tested at the end of each allocation funnel routine (see \VPageref{p:FunnelRoutine}), and if set, it is reset and a volunteer yield (context switch) is performed to allow other threads to execute.
 llheap uses two techniques to detect when execution is in a allocation operation or routine called from allocation operation, to abort any time slice during this period.
 On the slowpath when executing expensive operations, like @sbrk@ or @mmap@, interrupts are disabled/enabled by setting thread-local flags so the signal handler aborts immediately.
 On the fastpath, disabling/enabling interrupts is too expensive as accessing thread-local storage can be expensive and not thread-safe.
+llheap uses two techniques to detect when execution is in an allocation operation or routine called from allocation operation, to abort any time slice during this period.
+On the slowpath when executing expensive operations, like @sbrk@ or @mmap@, interrupts are disabled/enabled by setting kernel-thread-local flags so the signal handler aborts immediately.
+On the fastpath, disabling/enabling interrupts is too expensive as accessing kernel-thread-local storage can be expensive and not user-thread-safe.
 For example, the ARM processor stores the thread-local pointer in a coprocessor register that cannot perform atomic base-displacement addressing.
 Hence, there is a window between loading the thread-local pointer from the coprocessor register into a normal register and adding the displacement when a time slice can move a thread.
 The fast technique defines a special code section and places all non-interruptible routines in this section.
+Hence, there is a window between loading the kernel-thread-local pointer from the coprocessor register into a normal register and adding the displacement when a time slice can move a thread.
+The fast technique (with lower run time cost) is to define a special code section and places all non-interruptible routines in this section.
 The linker places all code in this section into a contiguous block of memory, but the order of routines within the block is unspecified.
 Then, the signal handler compares the program counter at the point of interrupt with the the start and end address of the non-interruptible section, and aborts if executing within this section and sets the rollforward flag.
 …
 Hence, for correctness, this approach requires inspection of generated assembler code for routines placed in the non-interruptible section.
 This issue is mitigated by the llheap funnel design so only funnel routines and a few statistics routines are placed in the non-interruptible section and their assembler code examined.
 These techniques are used in both the \uC and \CFA versions of llheap, where both of these systems have user-level threading.
+These techniques are used in both the \uC and \CFA versions of llheap as both of these systems have user-level threading.
 …
 Programs can be statically or dynamically linked.
 \item
 The order the linker schedules startup code is poorly supported.
+The order in which the linker schedules startup code is poorly supported so it cannot be controlled entirely.
 \item
 Knowing a KT's start and end independently from the KT code is difficult.
 …
 Hence, some part of the @sbrk@ area may be used by the default allocator and statistics about allocation operations cannot be correct.
 Furthermore, dynamic linking goes through trampolines, so there is an additional cost along the allocator fastpath for all allocation operations.
 Testing showed up to a 5\% performance increase for dynamic linking over static linking, even when using @tls_model("initial-exec")@ so the dynamic loader can obtain tighter binding.
+Testing showed up to a 5\% performance decrease with dynamic linking as compared to static linking, even when using @tls_model("initial-exec")@ so the dynamic loader can obtain tighter binding.
 All allocator libraries need to perform startup code to initialize data structures, such as the heap array for llheap.
 The problem is getting initialized done before the first allocator call.
+The problem is getting initialization done before the first allocator call.
 However, there does not seem to be mechanism to tell either the static or dynamic loader to first perform initialization code before any calls to a loaded library.
+Also, initialization code of other libraries and the run-time environment may call memory allocation routines such as \lstinline{malloc}.
+This compounds the situation as there is no mechanism to tell either the static or dynamic loader to first perform the initialization code of the memory allocator before any other initialization that may involve a dynamic memory allocation call.
 As a result, calls to allocation routines occur without initialization.
 To deal with this problem, it is necessary to put a conditional initialization check along the allocation fastpath to trigger initialization (singleton pattern).
 …
 Therefore, the constructor is useless for knowing when a KT starts because the KT must reference it, and the allocator does not control the application KT.
 Fortunately, the singleton pattern needed for initializing the program KT also triggers KT allocator initialization, which can then reference @pgm_thread@ to call @threadManager@'s constructor, otherwise its destructor is not called.
 Now when a KT terminates, @~ThreadManager@ is called to chained it onto the global-heap free-stack, where @pgm_thread@ is set to true only for the program KT.
+Now when a KT terminates, @~ThreadManager@ is called to chain it onto the global-heap free-stack, where @pgm_thread@ is set to true only for the program KT.
 The conditional destructor call prevents closing down the program heap, which must remain available because epilogue code may free more storage.
 …
 bool traceHeapOff();                    $\C{// stop printing allocation/free calls}$
 \end{lstlisting}
 This kind of API is necessary to allow concurrent runtime systems to interact with difference memory allocators in a consistent way.
+This kind of API is necessary to allow concurrent runtime systems to interact with different memory allocators in a consistent way.
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 …
 Most allocators use @nullptr@ to indicate an allocation failure, specifically out of memory;
 hence the need to return an alternate value for a zero-sized allocation.
 A different approach allowed by the C API is to abort a program when out of memory and return @nullptr@ for a zero-sized allocation.
+A different approach allowed by @C API@ is to abort a program when out of memory and return @nullptr@ for a zero-sized allocation.
 In theory, notifying the programmer of memory failure allows recovery;
 in practice, it is almost impossible to gracefully recover when out of memory.
 …
 \paragraph{\lstinline{void * aalloc( size_t dim, size_t elemSize )}}
 extends @calloc@ for allocating a dynamic array of objects without calculating the total size of array explicitly but \emph{without} zero-filling the memory.
 @aalloc@ is significantly faster than @calloc@, which is the only alternative.
+@aalloc@ is significantly faster than @calloc@, which is the only alternative given by the standard memory-allocation routines.
 \noindent\textbf{Usage}
 …
 \begin{itemize}
 \item
 @fd@: files description.
+@fd@: file descriptor.
 \end{itemize}
 It returns the previous file descriptor.
 …
 \label{p:malloc_expansion}
 set the amount (bytes) to extend the heap when there is insufficient free storage to service an allocation request.
 It returns the heap extension size used throughout a program, \ie called once at heap initialization.
+It returns the heap extension size used throughout a program when requesting more memory from the system using @sbrk@ system-call, \ie called once at heap initialization.
 \paragraph{\lstinline{size_t malloc_mmap_start()}}
 …
 \begin{itemize}
 \item
 naming: \CFA regular and @ttype@ polymorphism is used to encapsulate a wide range of allocation functionality into a single routine name, so programmers do not have to remember multiple routine names for different kinds of dynamic allocations.
 \item
 named arguments: individual allocation properties are specified using postfix function call, so programmers do have to remember parameter positions in allocation calls.
 \item
 object size: like the \CFA C-style interface, programmers do not have to specify object size or cast allocation results.
+naming: \CFA regular and @ttype@ polymorphism (@ttype@ polymorphism in \CFA is similar to \CC variadic templates) is used to encapsulate a wide range of allocation functionality into a single routine name, so programmers do not have to remember multiple routine names for different kinds of dynamic allocations.
+\item
+named arguments: individual allocation properties are specified using postfix function call, so the programmers do not have to remember parameter positions in allocation calls.
+\item
+object size: like the \CFA's C-interface, programmers do not have to specify object size or cast allocation results.
 \end{itemize}
 Note, postfix function call is an alternative call syntax, using backtick @`@, where the argument appears before the function name, \eg
 …
 duration dur = 3@`@h + 42@`@m + 17@`@s;
 \end{cfa}
-@ttype@ polymorphism is similar to \CC variadic templates.
 \paragraph{\lstinline{T * alloc( ... )} or \lstinline{T * alloc( size_t dim, ... )}}
+is overloaded with a variable number of specific allocation routines, or an integer dimension parameter followed by a variable number specific allocation routines.
+is overloaded with a variable number of specific allocation operations, or an integer dimension parameter followed by a variable number of specific allocation operations.
+These allocation operations can be passed as named arguments when calling the \lstinline{alloc} routine.
 A call without parameters returns a dynamically allocated object of type @T@ (@malloc@).
 A call with only the dimension (dim) parameter returns a dynamically allocated array of objects of type @T@ (@aalloc@).
 …
 5 5 -555819298 -555819298  // two undefined values
 \end{lstlisting}
 Examples 1 to 3, fill an object with a value or characters.
 Examples 4 to 7, fill an array of objects with values, another array, or part of an array.
+Examples 1 to 3 fill an object with a value or characters.
+Examples 4 to 7 fill an array of objects with values, another array, or part of an array.
 \subparagraph{\lstinline{S_resize(T) ?`resize( void * oaddr )}}
 …
 \subparagraph{\lstinline{S_realloc(T) ?`realloc( T * a ))}}
 used to resize, realign, and fill, where the old object data is copied to the new object.
 The old object type must be the same as the new object type, since the values used.
+The old object type must be the same as the new object type, since the value is used.
 Note, for @fill@, only the extra space after copying the data from the old object is filled with the given parameter.
 For example:
 …
 \end{lstlisting}
 Examples 2 to 3 change the alignment for the initial storage of @i@.
 The @13`fill@ for example 3 does nothing because no extra space is added.
+The @13`fill@ in example 3 does nothing because no extra space is added.
 \begin{cfa}[numbers=left]
 …
 \end{lstlisting}
 Examples 2 to 4 change the array size, alignment and fill for the initial storage of @ia@.
 The @13`fill@ for example 3 does nothing because no extra space is added.
+The @13`fill@ in example 3 does nothing because no extra space is added.
 These \CFA allocation features are used extensively in the development of the \CFA runtime.

doc/theses/mubeen_zulfiqar_MMath/background.tex

-              r015925a
+              re5d9274
 The management data starts with fixed-sized information in the static-data memory that references components in the dynamic-allocation memory.
 The \newterm{storage data} is composed of allocated and freed objects, and \newterm{reserved memory}.
 Allocated objects (light grey) are variable sized, and allocated and maintained by the program;
 \ie only the program knows the location of allocated storage, not the memory allocator.
+Allocated objects (light grey) are variable sized, and are allocated and maintained by the program;
+\ie only the memory allocator knows the location of allocated storage, not the program.
 \begin{figure}[h]
 \centering
 …
 if there are multiple reserved blocks, they are also chained together, usually internally.
 Allocated and freed objects typically have additional management data embedded within them.
+In some allocator designs, allocated and freed objects have additional management data embedded within them.
 \VRef[Figure]{f:AllocatedObject} shows an allocated object with a header, trailer, and alignment padding and spacing around the object.
 The header contains information about the object, \eg size, type, etc.
 …
 \VRef[Figure]{f:MemoryFragmentation} shows an example of how a small block of memory fragments as objects are allocated and deallocated over time.
 Blocks of free memory become smaller and non-contiguous making them less useful in serving allocation requests.
 Memory is highly fragmented when the sizes of most free blocks are unusable.
+Memory is highly fragmented when most free blocks are unusable because of their sizes.
 For example, \VRef[Figure]{f:Contiguous} and \VRef[Figure]{f:HighlyFragmented} have the same quantity of external fragmentation, but \VRef[Figure]{f:HighlyFragmented} is highly fragmented.
 If there is a request to allocate a large object, \VRef[Figure]{f:Contiguous} is more likely to be able to satisfy it with existing free memory, while \VRef[Figure]{f:HighlyFragmented} likely has to request more memory from the operating system.
 …
 The fewer bin-sizes, the fewer lists need to be searched and maintained;
 however, the bin sizes are less likely to closely fit the requested object size, leading to more internal fragmentation.
 The more bin-sizes, the longer the search and the less likely free objects are to be reused, leading to more external fragmentation and potentially heap blowup.
+The more bin sizes, the longer the search and the less likely free objects are to be reused, leading to more external fragmentation and potentially heap blowup.
 A variation of the binning algorithm allows objects to be allocated to the requested size, but when an object is freed, it is placed on the free list of the next smallest or equal bin-size.
 For example, with bin sizes of 8 and 16 bytes, a request for 12 bytes allocates only 12 bytes, but when the object is freed, it is placed on the 8-byte bin-list.
 …
 The principle of locality recognizes that programs tend to reference a small set of data, called a working set, for a certain period of time, where a working set is composed of temporal and spatial accesses~\cite{Denning05}.
 Temporal clustering implies a group of objects are accessed repeatedly within a short time period, while spatial clustering implies a group of objects physically close together (nearby addresses) are accessed repeatedly within a short time period.
 Temporal locality commonly occurs during an iterative computation with a fix set of disjoint variables, while spatial locality commonly occurs when traversing an array.
+Temporal locality commonly occurs during an iterative computation with a fixed set of disjoint variables, while spatial locality commonly occurs when traversing an array.
 Hardware takes advantage of temporal and spatial locality through multiple levels of caching, \ie memory hierarchy.
 …
 For example, multiple heaps are managed in a pool, starting with a single or a fixed number of heaps that increase\-/decrease depending on contention\-/space issues.
 At creation, a thread is associated with a heap from the pool.
 When the thread attempts an allocation and its associated heap is locked (contention), it scans for an unlocked heap in the pool.
+In some implementations of this model, when the thread attempts an allocation and its associated heap is locked (contention), it scans for an unlocked heap in the pool.
 If an unlocked heap is found, the thread changes its association and uses that heap.
 If all heaps are locked, the thread may create a new heap, use it, and then place the new heap into the pool;
 …
 The management information in the static zone must be able to locate all heaps in the dynamic zone.
 The management information for the heaps must reside in the dynamic-allocation zone if there are a variable number.
 Each heap in the dynamic zone is composed of a list of a free objects and a pointer to its reserved memory.
+Each heap in the dynamic zone is composed of a list of free objects and a pointer to its reserved memory.
 An alternative implementation is for all heaps to share one reserved memory, which requires a separate lock for the reserved storage to ensure mutual exclusion when acquiring new memory.
 Because multiple threads can allocate/free/reallocate adjacent storage, all forms of false sharing may occur.
 …
 Multiple heaps increase external fragmentation as the ratio of heaps to threads increases, which can lead to heap blowup.
 The external fragmentation experienced by a program with a single heap is now multiplied by the number of heaps, since each heap manages its own free storage and allocates its own reserved memory.
 Additionally, objects freed by one heap cannot be reused by other threads, except indirectly by returning free memory to the operating system, which can be expensive.
+(Depending on how the operating system provides dynamic storage to an application, returning storage may be difficult or impossible, \eg the contiguous @sbrk@ area in Unix.)
+Additionally, objects freed by one heap cannot be reused by other threads without increasing the cost of the memory operations, except indirectly by returning free memory to the operating system, which can be expensive.
+Depending on how the operating system provides dynamic storage to an application, returning storage may be difficult or impossible, \eg the contiguous @sbrk@ area in Unix.
 In the worst case, a program in which objects are allocated from one heap but deallocated to another heap means these freed objects are never reused.
 …
 In contrast, the T:H model spreads each thread's objects over a larger area in different heaps.
 Thread heaps can also eliminate allocator-induced active false-sharing, if memory is acquired so it does not overlap at crucial boundaries with memory for another thread's heap.
 For example, assume page boundaries coincide with cache line boundaries, then if a thread heap always acquires pages of memory, no two threads share a page or cache line unless pointers are passed among them.
+For example, assume page boundaries coincide with cache line boundaries, if a thread heap always acquires pages of memory then no two threads share a page or cache line unless pointers are passed among them.
 Hence, allocator-induced active false-sharing in \VRef[Figure]{f:AllocatorInducedActiveFalseSharing} cannot occur because the memory for thread heaps never overlaps.
 When a thread terminates, there are two options for handling its heap.
 First is to free all objects in the heap to the global heap and destroy the thread heap.
+When a thread terminates, there are two options for handling its thread heap.
+First is to free all objects in the thread heap to the global heap and destroy the thread heap.
 Second is to place the thread heap on a list of available heaps and reuse it for a new thread in the future.
 Destroying the thread heap immediately may reduce external fragmentation sooner, since all free objects are freed to the global heap and may be reused by other threads.
 Alternatively, reusing thread heaps may improve performance if the inheriting thread makes similar allocation requests as the thread that previously held the thread heap because any unfreed storage is immediately accessible..
+Alternatively, reusing thread heaps may improve performance if the inheriting thread makes similar allocation requests as the thread that previously held the thread heap because any unfreed storage is immediately accessible.
 …
 When the user thread continues on the new kernel thread, it may have pointers into the previous kernel-thread's heap and hold locks associated with it.
 To get the same kernel-thread safety, time slicing must be disabled/\-enabled around these operations, so the user thread cannot jump to another kernel thread.
 However, eagerly disabling/enabling time-slicing on the allocation/deallocation fast path is expensive, because preemption is rare (10--100 milliseconds).
+However, eagerly disabling/enabling time-slicing on the allocation/deallocation fast path is expensive, because preemption does not happen that frequently.
 Instead, techniques exist to lazily detect this case in the interrupt handler, abort the preemption, and return to the operation so it can complete atomically.
 Occasionally ignoring a preemption should be benign, but a persistent lack of preemption can result in both short and long term starvation.
-\begin{figure}
-\centering
-\subfigure[Ownership]{
-        \input{MultipleHeapsOwnership}
-} % subfigure
-\hspace{0.25in}
-\subfigure[No Ownership]{
-        \input{MultipleHeapsNoOwnership}
-} % subfigure
-\caption{Heap Ownership}
-\label{f:HeapsOwnership}
-\end{figure}
 …
 For the T:1/T:H models with or without ownership or the 1:1 model with ownership, a thread may free objects to different heaps, which makes each heap publicly accessible to all threads, called a \newterm{public heap}.
+\begin{figure}
+\centering
+\subfigure[Ownership]{
+        \input{MultipleHeapsOwnership}
+} % subfigure
+\hspace{0.25in}
+\subfigure[No Ownership]{
+        \input{MultipleHeapsNoOwnership}
+} % subfigure
+\caption{Heap Ownership}
+\label{f:HeapsOwnership}
+\end{figure}
 \VRef[Figure]{f:MultipleHeapStorageOwnership} shows the effect of ownership on storage layout.
 (For simplicity assume the heaps all use the same size of reserves storage.)
+(For simplicity, assume the heaps all use the same size of reserves storage.)
 In contrast to \VRef[Figure]{f:MultipleHeapStorage}, each reserved area used by a heap only contains free storage for that particular heap because threads must return free objects back to the owner heap.
 Again, because multiple threads can allocate/free/reallocate adjacent storage in the same heap, all forms of false sharing may occur.
 …
 While the returning thread can batch objects, batching across multiple heaps is complex and there is no obvious time when to push back to the owner heap.
 It is better for returning threads to immediately return to the receiving thread's batch list as the receiving thread has better knowledge when to incorporate the batch list into its free pool.
 Batching leverages the fact that most allocation patterns use the contention-free fast-path so locking on the batch list is rare for both the returning and receiving threads.
 It is possible for heaps to steal objects rather than return them and reallocating these objects when storage runs out on a heap.
+Batching leverages the fact that most allocation patterns use the contention-free fast-path, so locking on the batch list is rare for both the returning and receiving threads.
+It is possible for heaps to steal objects rather than return them and then reallocate these objects again when storage runs out on a heap.
 However, stealing can result in passive false-sharing.
 For example, in \VRef[Figure]{f:AllocatorInducedPassiveFalseSharing}, Object$_2$ may be deallocated to Thread$_2$'s heap initially.
 …
 Bracketing every allocation with headers/trailers can result in significant internal fragmentation, as shown in \VRef[Figure]{f:ObjectHeaders}.
 Especially if the headers contain redundant management information, \eg object size may be the same for many objects because programs only allocate a small set of object sizes.
+Especially if the headers contain redundant management information, then storing that information is a waste of storage, \eg object size may be the same for many objects because programs only allocate a small set of object sizes.
 As well, it can result in poor cache usage, since only a portion of the cache line is holding useful information from the program's perspective.
 Spatial locality can also be negatively affected leading to poor cache locality~\cite{Feng05}:
 …
 With local free-lists in containers, as in \VRef[Figure]{f:LocalFreeListWithinContainers}, the container is simply removed from one heap's free list and placed on the new heap's free list.
 Thus, when using local free-lists, the operation of moving containers is reduced from $O(N)$ to $O(1)$.
 The cost is adding information to a header, which increases the header size, and therefore internal fragmentation.
+However, there is the additional storage cost in the header, which increases the header size, and therefore internal fragmentation.
 \begin{figure}
 …
 The main goal of the hybrid approach is to eliminate locking on thread-local allocation/deallocation, while providing ownership to prevent heap blowup.
 In the hybrid approach, a thread first allocates from its private heap and second from its public heap if no free memory exists in the private heap.
 Similarly, a thread first deallocates an object its private heap, and second to the public heap.
+Similarly, a thread first deallocates an object to its private heap, and second to the public heap.
 Both private and public heaps can allocate/deallocate to/from the global heap if there is no free memory or excess free memory, although an implementation may choose to funnel all interaction with the global heap through one of the heaps.
 Note, deallocation from the private to the public (dashed line) is unlikely because there is no obvious advantages unless the public heap provides the only interface to the global heap.

doc/theses/mubeen_zulfiqar_MMath/benchmarks.tex

-              r015925a
+              re5d9274
 \item[Benchmarks]
 are a suite of application programs (SPEC CPU/WEB) that are exercised in a common way (inputs) to find differences among underlying software implementations associated with an application (compiler, memory allocator, web server, \etc).
 The applications are suppose to represent common execution patterns that need to perform well with respect to an underlying software implementation.
+The applications are supposed to represent common execution patterns that need to perform well with respect to an underlying software implementation.
 Benchmarks are often criticized for having overlapping patterns, insufficient patterns, or extraneous code that masks patterns.
 \item[Micro-Benchmarks]
 …
 This thesis designs and examines a new set of micro-benchmarks for memory allocators that test a variety of allocation patterns, each with multiple tuning parameters.
 The aim of the micro-benchmark suite is to create a set of programs that can evaluate a memory allocator based on the key performance matrices such as speed, memory overhead, and cache performance.
+The aim of the micro-benchmark suite is to create a set of programs that can evaluate a memory allocator based on the key performance metrics such as speed, memory overhead, and cache performance.
 % These programs can be taken as a standard to benchmark an allocator's basic goals.
 These programs give details of an allocator's memory overhead and speed under certain allocation patterns.
 The allocation patterns are configurable (adjustment knobs) to observe an allocator's performance across a spectrum of events for a desired allocation pattern, which is seldom possible with benchmark programs.
+The allocation patterns are configurable (adjustment knobs) to observe an allocator's performance across a spectrum allocation patterns, which is seldom possible with benchmark programs.
 Each micro-benchmark program has multiple control knobs specified by command-line arguments.
 The new micro-benchmark suite measures performance by allocating dynamic objects and measuring specific matrices.
+The new micro-benchmark suite measures performance by allocating dynamic objects and measuring specific metrics.
 An allocator's speed is benchmarked in different ways, as are issues like false sharing.
 …
 Modern memory allocators, such as llheap, must handle multi-threaded programs at the KT and UT level.
 The following multi-threaded micro-benchmarks are presented to give a sense of prior work~\cite{Berger00} at the KT level.
 None of the prior work address multi-threading at the UT level.
+None of the prior work addresses multi-threading at the UT level.
 …
 This benchmark stresses the ability of the allocator to handle different threads allocating and deallocating independently.
 There is no interaction among threads, \ie no object sharing.
 Each thread repeatedly allocate 100,000 \emph{8-byte} objects then deallocates them in the order they were allocated.
 Runtime of the benchmark evaluates its efficiency.
+Each thread repeatedly allocates 100,000 \emph{8-byte} objects then deallocates them in the order they were allocated.
+The execution time of the benchmark evaluates its efficiency.
 …
 Before the thread terminates, it passes its array of 10,000 objects to a new child thread to continue the process.
 The number of thread generations varies depending on the thread speed.
 It calculates memory operations per second as an indicator of memory allocator's performance.
+It calculates memory operations per second as an indicator of the memory allocator's performance.
 …
 \label{s:ChurnBenchmark}
 The churn benchmark measures the runtime speed of an allocator in a multi-threaded scenerio, where each thread extensively allocates and frees dynamic memory.
+The churn benchmark measures the runtime speed of an allocator in a multi-threaded scenario, where each thread extensively allocates and frees dynamic memory.
 Only @malloc@ and @free@ are used to eliminate any extra cost, such as @memcpy@ in @calloc@ or @realloc@.
 Churn simulates a memory intensive program that can be tuned to create different scenarios.
+Churn simulates a memory intensive program and can be tuned to create different scenarios.
 \VRef[Figure]{fig:ChurnBenchFig} shows the pseudo code for the churn micro-benchmark.
 …
 When threads share a cache line, frequent reads/writes to their cache-line object causes cache misses, which cause escalating delays as cache distance increases.
 Cache thrash tries to create a scenerio that leads to false sharing, if the underlying memory allocator is allocating dynamic memory to multiple threads on the same cache lines.
+Cache thrash tries to create a scenario that leads to false sharing, if the underlying memory allocator is allocating dynamic memory to multiple threads on the same cache lines.
 Ideally, a memory allocator should distance the dynamic memory region of one thread from another.
 Having multiple threads allocating small objects simultaneously can cause a memory allocator to allocate objects on the same cache line, if its not distancing the memory among different threads.
 …
 Each worker thread allocates an object and intensively reads/writes it for M times to possible invalidate cache lines that may interfere with other threads sharing the same cache line.
 Each thread repeats this for N times.
 The main thread measures the total time taken to for all worker threads to complete.
 Worker threads sharing cache lines with each other will take longer.
+The main thread measures the total time taken for all worker threads to complete.
+Worker threads sharing cache lines with each other are expected to take longer.
 \begin{figure}
 …
         signal workers to free
         ...
-        print addresses from each $thread$
 Worker Thread$\(_1\)$
         allocate, write, read, free
         warmup memory in chunkc of 16 bytes
         ...
         malloc N objects
         ...
         free objects
         return object address to Main Thread
+        warm up memory in chunks of 16 bytes
+        ...
+        For N
+                malloc an object
+                read/write the object M times
+                free the object
+        ...
 Worker Thread$\(_2\)$
         // same as Worker Thread$\(_1\)$
 …
 The cache-scratch micro-benchmark measures allocator-induced passive false-sharing as illustrated in \VRef{s:AllocatorInducedPassiveFalseSharing}.
 As for cache thrash, if memory is allocated for multiple threads on the same cache line, this can significantly slow down program performance.
+As with cache thrash, if memory is allocated for multiple threads on the same cache line, this can significantly slow down program performance.
 In this scenario, the false sharing is being caused by the memory allocator although it is started by the program sharing an object.
 …
 Cache scratch tries to create a scenario that leads to false sharing and should make the memory allocator preserve the program-induced false sharing, if it does not return a freed object to its owner thread and, instead, re-uses it instantly.
 An allocator using object ownership, as described in section \VRef{s:Ownership}, is less susceptible to allocator-induced passive false-sharing.
 If the object is returned to the thread who owns it, then the thread that gets a new object is less likely to be on the same cache line.
+If the object is returned to the thread that owns it, then the new object that the thread gets is less likely to be on the same cache line.
 \VRef[Figure]{fig:benchScratchFig} shows the pseudo code for the cache-scratch micro-benchmark.
 …
         signal workers to free
         ...
-        print addresses from each $thread$
 Worker Thread$\(_1\)$
+        allocate, write, read, free
+        warmup memory in chunkc of 16 bytes
+        ...
+        for ( N )
+                free an object passed by Main Thread
+        warmup memory in chunks of 16 bytes
+        ...
+        free the object passed by the Main Thread
+        For N
                 malloc new object
         ...
         free objects
         return new object addresses to Main Thread
+                read/write the object M times
+                free the object
+        ...
 Worker Thread$\(_2\)$
         // same as Worker Thread$\(_1\)$
 …
 Similar to benchmark cache thrash in section \VRef{sec:benchThrashSec}, different cache access scenarios can be created using the following command-line arguments.
 \begin{description}[itemsep=0pt,parsep=0pt]
+\begin{description}[topsep=0pt,itemsep=0pt,parsep=0pt]
 \item[threads:]
 number of threads (K).
 …
 \subsection{Speed Micro-Benchmark}
 \label{s:SpeedMicroBenchmark}
+\vspace*{-4pt}
 The speed benchmark measures the runtime speed of individual and sequences of memory allocation routines:
 \begin{enumerate}[itemsep=0pt,parsep=0pt]
+\begin{enumerate}[topsep=-5pt,itemsep=0pt,parsep=0pt]
 \item malloc
 \item realloc
 …
 \VRef[Figure]{fig:MemoryBenchFig} shows the pseudo code for the memory micro-benchmark.
 It creates a producer-consumer scenario with K producer threads and each producer has M consumer threads.
 A producer has a separate buffer for each consumer and allocates N objects of random sizes following a settable distribution for each consumer.
+A producer has a separate buffer for each consumer and allocates N objects of random sizes following a configurable distribution for each consumer.
 A consumer frees these objects.
 After every memory operation, program memory usage is recorded throughout the runtime.

doc/theses/mubeen_zulfiqar_MMath/conclusion.tex

-              r015925a
+              re5d9274
 % ====================
 The goal of this thesis was to build a low-latency memory allocator for both KT and UT multi-threads systems, which is competitive with the best current memory allocators, while extending the feature set of existing and new allocator routines.
+The goal of this thesis was to build a low-latency (or high bandwidth) memory allocator for both KT and UT multi-threading systems that is competitive with the best current memory allocators while extending the feature set of existing and new allocator routines.
 The new llheap memory-allocator achieves all of these goals, while maintaining and managing sticky allocation information without a performance loss.
 Hence, it becomes possible to use @realloc@ frequently as a safe operation, rather than just occasionally.
 Furthermore, the ability to query sticky properties and information allows programmers to write safer programs, as it is possible to dynamically match allocation styles from unknown library routines that return allocations.
 Extending the C allocation API with @resize@, advanced @realloc@, @aalloc@, @amemalign@, and @cmemalign@ means programmers do not make mistakes writing theses useful allocation operations.
+Extending the C allocation API with @resize@, advanced @realloc@, @aalloc@, @amemalign@, and @cmemalign@ means programmers do not have to do these useful allocation operations themselves.
 The ability to use \CFA's advanced type-system (and possibly \CC's too) to have one allocation routine with completely orthogonal sticky properties shows how far the allocation API can be pushed, which increases safety and greatly simplifies programmer's use of dynamic allocation.
 Providing comprehensive statistics for all allocation operations is invaluable in understanding and debugging a program's dynamic behaviour.
 No other memory allocator provides comprehensive statistics gathering.
+No other memory allocator provides such comprehensive statistics gathering.
 This capability was used extensively during the development of llheap to verify its behaviour.
 As well, providing a debugging mode where allocations are checked, along with internal pre/post conditions and invariants, is extremely useful, especially for students.
 While not as powerful as the @valgrind@ interpreter, a large number of allocations mistakes are detected.
+While not as powerful as the @valgrind@ interpreter, a large number of allocation mistakes are detected.
 Finally, contention-free statistics gathering and debugging have a low enough cost to be used in production code.
 …
 Starting a micro-benchmark test-suite for comparing allocators, rather than relying on a suite of arbitrary programs, has been an interesting challenge.
 The current micro-benchmarks allow some understand of allocator implementation properties without actually looking at the implementation.
+The current micro-benchmarks allow some understanding of allocator implementation properties without actually looking at the implementation.
 For example, the memory micro-benchmark quickly identified how several of the allocators work at the global level.
 It was not possible to show how the micro-benchmarks adjustment knobs were used to tune to an interesting test point.
 …
 A careful walk-though of the allocator fastpath should yield additional optimizations for a slight performance gain.
 In particular, looking at the implementation of rpmalloc, which is often the fastest allocator,
+In particular, analysing the implementation of rpmalloc, which is often the fastest allocator,
 The micro-benchmarks project requires more testing and analysis.
 Additional allocations patterns are needed to extract meaningful information about allocators, and within allocation patterns, what are the best tuning knobs.
+The micro-benchmark project requires more testing and analysis.
+Additional allocation patterns are needed to extract meaningful information about allocators, and within allocation patterns, what are the most useful tuning knobs.
 Also, identifying ways to visualize the results of the micro-benchmarks is a work in progress.
 After llheap is made available on gitHub, interacting with its users to locate problems and improvements, will make llbench a more robust memory allocator.
 As well, feedback from the \uC and \CFA projects, which have adopted llheap for their memory allocator, will provide additional feedback.
+After llheap is made available on GitHub, interacting with its users to locate problems and improvements will make llbench a more robust memory allocator.
+As well, feedback from the \uC and \CFA projects, which have adopted llheap for their memory allocator, will provide additional information.

doc/theses/mubeen_zulfiqar_MMath/figures/Header.fig

-              r015925a
+              re5d9274
 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2
 1500 3300 2400
+2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+1800 6600 1800 6600 2100 4200 2100 4200 1800
 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 3
 1 1.00 45.00 90.00
 2625 3750 2625 3750 2400
+2775 3750 2775 3750 1725
 1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 3
 1 1.00 45.00 90.00
+2850 3450 2850 3450 2400
+2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
+1800 6600 1800 6600 2100 4200 2100 4200 1800
+2550 4050 2550 4050 1725
+1 0 1 0 7 50 -1 -1 4.000 0 0 -1 1 0 3
+1 1.00 45.00 90.00
+3000 3450 3000 3450 2025
 0 0 50 -1 0 12 0.0000 2 180 1185 1875 1725 bucket pointer\001
 0 0 50 -1 0 12 0.0000 2 180 1005 1875 2025 mapped size\001
 0 0 50 -1 0 12 0.0000 2 135 1215 1875 2325 next free block\001
 2 0 50 -1 0 12 0.0000 2 135 480 1725 2025 union\001
-1 0 50 -1 0 12 0.0000 2 135 270 3775 2325 0/1\001
-1 0 50 -1 0 12 0.0000 2 135 270 3475 2325 0/1\001
 1 0 50 -1 0 12 0.0000 2 180 945 5400 2025 request size\001
 1 0 50 -1 0 12 0.0000 2 180 765 5400 1425 4/8-bytes\001
 1 0 50 -1 0 12 0.0000 2 180 765 3000 1425 4/8-bytes\001
+0 0 50 -1 0 12 0.0000 2 135 825 4125 2700 zero filled\001
+0 0 50 -1 0 12 0.0000 2 180 1515 4125 2925 mapped allocation\001
+1 0 50 -1 0 12 0.0000 2 135 270 3475 2025 0/1\001
+1 0 50 -1 0 12 0.0000 2 135 270 3775 1725 0/1\001
+1 0 50 -1 0 12 0.0000 2 135 270 4075 1725 0/1\001
+0 0 50 -1 0 12 0.0000 2 180 1515 4275 3075 mapped allocation\001
+0 0 50 -1 0 12 0.0000 2 135 825 4275 2850 zero filled\001
+0 0 50 -1 0 12 0.0000 2 180 1920 4275 2625 alignment (fake header)\001

doc/theses/mubeen_zulfiqar_MMath/figures/MultipleHeapsNoOwnership.fig

-              r015925a
+              re5d9274
 #FIG 3.2  Produced by xfig version 3.2.5
+#FIG 3.2  Produced by xfig version 3.2.7b
 Landscape
 Center
 Inches
 Letter
+Letter
 .00
 Single
 …
 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
 2100 1500 2100 1500 1800 1200 1800 1200 2100
 1 0 50 -1 0 11 0.0000 2 195 495 1350 2025 H$_1$\001
+1 0 50 -1 0 11 0.0000 2 165 495 1350 2025 H$_1$\001
 -6
 1950 1800 2550 2100
 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
 2100 2400 2100 2400 1800 2100 1800 2100 2100
 1 0 50 -1 0 11 0.0000 2 195 495 2250 2025 H$_2$\001
+1 0 50 -1 0 11 0.0000 2 165 495 2250 2025 H$_2$\001
 -6
 3 0 1 0 7 50 -1 -1 0.000 0 -0.0000 1350 1350 150 150 1350 1350 1500 1350
 3 0 1 0 7 50 -1 -1 0.000 0 -0.0000 2250 1350 150 150 2250 1350 2400 1350
 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
 0 1.00 45.00 90.00
 0 1.00 45.00 90.00
+1 1.00 45.00 90.00
+1 1.00 45.00 90.00
 1800 1275 1500
 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
 0 1.00 45.00 90.00
+1 0 1 0 0 50 -1 -1 0.000 0 0 -1 1 0 2
+1 1.00 45.00 90.00
 1500 1425 1800
 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
 0 1.00 45.00 90.00
+1 1.00 45.00 90.00
 1500 2175 1800
 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 1 2
 0 1.00 45.00 90.00
+1 1.00 45.00 90.00
 1500 1425 1800
 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2
 0 1.00 45.00 90.00
+1 1.00 45.00 90.00
 1500 2175 1800
 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
 0 1.00 45.00 90.00
 0 1.00 45.00 90.00
+1 1.00 45.00 90.00
+1 1.00 45.00 90.00
 1800 2325 1500
 1 0 50 -1 0 11 0.0000 2 195 465 1350 1425 T$_1$\001
 1 0 50 -1 0 11 0.0000 2 195 465 2250 1425 T$_2$\001
+1 0 50 -1 0 11 0.0000 2 165 465 1350 1425 T$_1$\001
+1 0 50 -1 0 11 0.0000 2 165 465 2250 1425 T$_2$\001

doc/theses/mubeen_zulfiqar_MMath/figures/MultipleHeapsOwnership.fig

-              r015925a
+              re5d9274
 #FIG 3.2  Produced by xfig version 3.2.5
+#FIG 3.2  Produced by xfig version 3.2.7b
 Landscape
 Center
 Inches
 Letter
+Letter
 .00
 Single
 …
 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
 2100 1500 2100 1500 1800 1200 1800 1200 2100
 1 0 50 -1 0 11 0.0000 2 195 495 1350 2025 H$_1$\001
+1 0 50 -1 0 11 0.0000 2 165 495 1350 2025 H$_1$\001
 -6
 1950 1800 2550 2100
 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
 2100 2400 2100 2400 1800 2100 1800 2100 2100
 1 0 50 -1 0 11 0.0000 2 195 495 2250 2025 H$_2$\001
+1 0 50 -1 0 11 0.0000 2 165 495 2250 2025 H$_2$\001
 -6
 3 0 1 0 7 50 -1 -1 0.000 0 -0.0000 1350 1350 150 150 1350 1350 1500 1350
 3 0 1 0 7 50 -1 -1 0.000 0 -0.0000 2250 1350 150 150 2250 1350 2400 1350
 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
 0 1.00 45.00 90.00
 0 1.00 45.00 90.00
+1 1.00 45.00 90.00
+1 1.00 45.00 90.00
 1500 1425 1800
 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
+0 1.00 45.00 90.00
+0 1.00 45.00 90.00
+1500 2175 1800
+1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
+0 1.00 45.00 90.00
+0 1.00 45.00 90.00
+1 1.00 45.00 90.00
+1 1.00 45.00 90.00
 1800 1275 1500
 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
 0 1.00 45.00 90.00
 0 1.00 45.00 90.00
+1 1.00 45.00 90.00
+1 1.00 45.00 90.00
 1800 2325 1500
+1 0 50 -1 0 11 0.0000 2 195 465 2250 1425 T$_2$\001
+1 0 50 -1 0 11 0.0000 2 195 465 1350 1425 T$_1$\001
+1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
+1 1.00 45.00 90.00
+1 1.00 45.00 90.00
+1500 2175 1800
+1 0 50 -1 0 11 0.0000 2 165 465 2250 1425 T$_2$\001
+1 0 50 -1 0 11 0.0000 2 165 465 1350 1425 T$_1$\001

doc/theses/mubeen_zulfiqar_MMath/figures/PerThreadHeap.fig

-              r015925a
+              re5d9274
 #FIG 3.2  Produced by xfig version 3.2.5
+#FIG 3.2  Produced by xfig version 3.2.7b
 Landscape
 Center
 Inches
 Letter
+Letter
 .00
 Single
 …
 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
 1800 3000 1800 3000 2100 2700 2100 2700 1800
 1 0 50 -1 0 11 0.0000 2 135 135 2850 2025 G\001
+1 0 50 -1 0 11 0.0000 2 120 135 2850 2025 G\001
 -6
 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1350 1350 150 150 1350 1350 1500 1350
 …
 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 2250 1350 150 150 2250 1350 2400 1350
 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
 0 1.00 45.00 90.00
 0 1.00 45.00 90.00
+1 1.00 45.00 90.00
+1 1.00 45.00 90.00
 1500 1350 1800
 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
 …
 1800 2400 1800 2400 2100 2100 2100 2100 1800
 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
 0 1.00 45.00 90.00
 0 1.00 45.00 90.00
+1 1.00 45.00 90.00
+1 1.00 45.00 90.00
 1500 1800 1800
 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
 0 1.00 45.00 90.00
 0 1.00 45.00 90.00
+1 1.00 45.00 90.00
+1 1.00 45.00 90.00
 1500 2250 1800
 1 0 50 -1 0 11 0.0000 2 195 1320 2550 2025 $\\Leftrightarrow$\001
 1 0 50 -1 0 11 0.0000 2 195 1320 3150 2025 $\\Leftrightarrow$\001
 0 0 50 -1 0 11 0.0000 2 135 240 3300 2025 OS\001
 1 0 50 -1 0 11 0.0000 2 195 495 1350 2025 H$_1$\001
 1 0 50 -1 0 11 0.0000 2 195 465 1350 1425 T$_1$\001
 1 0 50 -1 0 11 0.0000 2 195 495 1800 2025 H$_2$\001
 1 0 50 -1 0 11 0.0000 2 195 465 1800 1425 T$_2$\001
 1 0 50 -1 0 11 0.0000 2 195 495 2250 2025 H$_3$\001
 1 0 50 -1 0 11 0.0000 2 195 465 2250 1425 T$_3$\001
+1 0 50 -1 0 11 0.0000 2 180 1260 2550 2025 $\\Leftrightarrow$\001
+1 0 50 -1 0 11 0.0000 2 180 1260 3150 2025 $\\Leftrightarrow$\001
+0 0 50 -1 0 11 0.0000 2 120 240 3300 2025 OS\001
+1 0 50 -1 0 11 0.0000 2 165 495 1350 2025 H$_1$\001
+1 0 50 -1 0 11 0.0000 2 165 465 1350 1425 T$_1$\001
+1 0 50 -1 0 11 0.0000 2 165 495 1800 2025 H$_2$\001
+1 0 50 -1 0 11 0.0000 2 165 465 1800 1425 T$_2$\001
+1 0 50 -1 0 11 0.0000 2 165 495 2250 2025 H$_3$\001
+1 0 50 -1 0 11 0.0000 2 165 465 2250 1425 T$_3$\001

doc/theses/mubeen_zulfiqar_MMath/figures/SharedHeaps.fig

-              r015925a
+              re5d9274
 #FIG 3.2  Produced by xfig version 3.2.5
+#FIG 3.2  Produced by xfig version 3.2.7b
 Landscape
 Center
 Inches
 Letter
+Letter
 .00
 Single
 …
 1500 1200 2100 1500
 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1800 1350 150 150 1800 1350 1950 1350
 1 0 50 -1 0 11 0.0000 2 195 465 1800 1425 T$_2$\001
+1 0 50 -1 0 11 0.0000 2 165 465 1800 1425 T$_2$\001
 -6
 1050 1200 1650 1500
 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1350 1350 150 150 1350 1350 1500 1350
 1 0 50 -1 0 11 0.0000 2 195 465 1350 1425 T$_1$\001
+1 0 50 -1 0 11 0.0000 2 165 465 1350 1425 T$_1$\001
 -6
 1950 1200 2550 1500
 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 2250 1350 150 150 2250 1350 2400 1350
 1 0 50 -1 0 11 0.0000 2 195 465 2250 1425 T$_3$\001
+1 0 50 -1 0 11 0.0000 2 165 465 2250 1425 T$_3$\001
 -6
 1275 1800 1875 2100
 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
 1800 1725 1800 1725 2100 1425 2100 1425 1800
 1 0 50 -1 0 11 0.0000 2 195 495 1575 2025 H$_1$\001
+1 0 50 -1 0 11 0.0000 2 165 495 1575 2025 H$_1$\001
 -6
 1725 1800 2325 2100
 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
 1800 2175 1800 2175 2100 1875 2100 1875 1800
 1 0 50 -1 0 11 0.0000 2 195 495 2025 2025 H$_2$\001
+1 0 50 -1 0 11 0.0000 2 165 495 2025 2025 H$_2$\001
 -6
 2475 1800 2775 2100
 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
 1800 2775 1800 2775 2100 2475 2100 2475 1800
 1 0 50 -1 0 11 0.0000 2 135 135 2625 2025 G\001
+1 0 50 -1 0 11 0.0000 2 120 135 2625 2025 G\001
 -6
 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
 0 1.00 45.00 90.00
 0 1.00 45.00 90.00
+1 1.00 45.00 90.00
+1 1.00 45.00 90.00
 1500 1500 1800
 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
 0 1.00 45.00 90.00
 0 1.00 45.00 90.00
+1 1.00 45.00 90.00
+1 1.00 45.00 90.00
 1500 1950 1800
 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
 0 1.00 45.00 90.00
 0 1.00 45.00 90.00
+1 1.00 45.00 90.00
+1 1.00 45.00 90.00
 1500 1650 1800
 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
 0 1.00 45.00 90.00
 0 1.00 45.00 90.00
+1 1.00 45.00 90.00
+1 1.00 45.00 90.00
 1500 2025 1800
 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
 0 1.00 45.00 90.00
 0 1.00 45.00 90.00
+1 1.00 45.00 90.00
+1 1.00 45.00 90.00
 1500 2100 1800
 0 0 50 -1 0 11 0.0000 2 135 240 3075 2025 OS\001
 1 0 50 -1 0 11 0.0000 2 195 1320 2325 2025 $\\Leftrightarrow$\001
 1 0 50 -1 0 11 0.0000 2 195 1320 2925 2025 $\\Leftrightarrow$\001
+0 0 50 -1 0 11 0.0000 2 120 240 3075 2025 OS\001
+1 0 50 -1 0 11 0.0000 2 180 1260 2325 2025 $\\Leftrightarrow$\001
+1 0 50 -1 0 11 0.0000 2 180 1260 2925 2025 $\\Leftrightarrow$\001

doc/theses/mubeen_zulfiqar_MMath/figures/SingleHeap.fig

-              r015925a
+              re5d9274
 #FIG 3.2  Produced by xfig version 3.2.5
+#FIG 3.2  Produced by xfig version 3.2.7b
 Landscape
 Center
 Inches
 Letter
+Letter
 .00
 Single
 …
 1500 1200 2100 1500
 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1800 1350 150 150 1800 1350 1950 1350
 1 0 50 -1 0 11 0.0000 2 195 465 1800 1425 T$_2$\001
+1 0 50 -1 0 11 0.0000 2 165 465 1800 1425 T$_2$\001
 -6
 1050 1200 1650 1500
 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 1350 1350 150 150 1350 1350 1500 1350
 1 0 50 -1 0 11 0.0000 2 195 465 1350 1425 T$_1$\001
+1 0 50 -1 0 11 0.0000 2 165 465 1350 1425 T$_1$\001
 -6
 1950 1200 2550 1500
 3 0 1 0 7 50 -1 -1 0.000 1 0.0000 2250 1350 150 150 2250 1350 2400 1350
 1 0 50 -1 0 11 0.0000 2 195 465 2250 1425 T$_3$\001
+1 0 50 -1 0 11 0.0000 2 165 465 2250 1425 T$_3$\001
 -6
 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
 0 1.00 45.00 90.00
 0 1.00 45.00 90.00
+1 1.00 45.00 90.00
+1 1.00 45.00 90.00
 1500 1725 1800
 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
 0 1.00 45.00 90.00
 0 1.00 45.00 90.00
+1 1.00 45.00 90.00
+1 1.00 45.00 90.00
 1500 1875 1800
 2 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 5
 1800 1950 1800 1950 2100 1650 2100 1650 1800
 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
 0 1.00 45.00 90.00
 0 1.00 45.00 90.00
+1 1.00 45.00 90.00
+1 1.00 45.00 90.00
 1500 1800 1800
 1 0 50 -1 0 11 0.0000 2 195 495 1800 2025 H$_1$\001
 1 0 50 -1 0 11 0.0000 2 195 1320 2100 2025 $\\Leftrightarrow$\001
 0 0 50 -1 0 11 0.0000 2 135 240 2250 2025 OS\001
+1 0 50 -1 0 11 0.0000 2 165 495 1800 2025 H$_1$\001
+1 0 50 -1 0 11 0.0000 2 180 1260 2100 2025 $\\Leftrightarrow$\001
+0 0 50 -1 0 11 0.0000 2 120 240 2250 2025 OS\001

doc/theses/mubeen_zulfiqar_MMath/figures/UserKernelHeaps.fig

-              r015925a
+              re5d9274
 -6
 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
 0 1.00 45.00 90.00
 0 1.00 45.00 90.00
+1 1.00 45.00 90.00
+1 1.00 45.00 90.00
 2100 2025 2400
 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
 0 1.00 45.00 90.00
 0 1.00 45.00 90.00
+1 1.00 45.00 90.00
+1 1.00 45.00 90.00
 2100 2475 2400
 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 1 2
 0 1.00 45.00 90.00
 0 1.00 45.00 90.00
+1 1.00 45.00 90.00
+1 1.00 45.00 90.00
 2100 2925 2400
 1 0 50 -1 0 11 0.0000 2 135 2235 2475 1725 scheduled across kernel threads\001

doc/theses/mubeen_zulfiqar_MMath/intro.tex

-              r015925a
+              re5d9274
 When this allocator proves inadequate, programmers often write specialize allocators for specific needs.
 C and \CC allow easy replacement of the default memory allocator with an alternative specialized or general-purpose memory-allocator.
+(Jikes RVM MMTk~\cite{MMTk} provides a similar generalization for the Java virtual machine.)
+Jikes RVM MMTk~\cite{MMTk} provides a similar generalization for the Java virtual machine.
 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}.
 …
 \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 the programming languages \uC and \CFA using user-level threads running over multiple kernel threads (M:N threading).
+\item
+Adopt @nullptr@ return for a zero-sized allocation, rather than an actual memory address, which can be passed to @free@.
+Implementation of a new stand-alone 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 the programming languages \uC and \CFA using user-level threads running over multiple kernel threads (M:N threading).
 \item
 …
 \item
 Provide additional heap wrapper functions in \CFA creating an orthogonal set of allocation operations and properties.
+Provide additional heap wrapper functions in \CFA creating a more usable set of allocation operations and properties.
 \item
 …
 \item
 @malloc_alignment( addr )@ returns the alignment of the allocation pointed-to by @addr@.
 If the allocation is not aligned or @addr@ is the @nulladdr@, the minimal alignment is returned.
+If the allocation is not aligned or @addr@ is the @NULL@, the minimal alignment is returned.
 \item
 @malloc_zero_fill( addr )@ returns a boolean result indicating if the memory pointed-to by @addr@ is allocated with zero fill, e.g., by @calloc@/@cmemalign@.
 …
 @malloc_usable_size( addr )@ returns the usable (total) size of the memory pointed-to by @addr@, i.e., the bin size containing the allocation, where @malloc_size( addr )@ $\le$ @malloc_usable_size( addr )@.
 \end{itemize}
-\item
-Provide mostly contention-free allocation and free operations via a heap-per-kernel-thread implementation.
 \item
 …
 \item
 Provide extensive runtime checks to valid allocation operations and identify the amount of unfreed storage at program termination.
+Provide extensive runtime checks to validate allocation operations and identify the amount of unfreed storage at program termination.
 \item

doc/theses/mubeen_zulfiqar_MMath/performance.tex

-              r015925a
+              re5d9274
 This chapter uses the micro-benchmarks from \VRef[Chapter]{s:Benchmarks} to test a number of current memory allocators, including llheap.
 The goal is to see if llheap is competitive with the current best memory allocators.
+The goal is to see if llheap is competitive with the currently popular memory allocators.
 …
 \begin{itemize}
 \item
+\textbf{Algol} Huawei ARM TaiShan 2280 V2 Kunpeng 920, 24-core socket $\times$ 4, 2.6 GHz, GCC version 9.4.0
+\item
 \textbf{Nasus} AMD EPYC 7662, 64-core socket $\times$ 2, 2.0 GHz, GCC version 9.3.0
-\item
-\textbf{Algol} Huawei ARM TaiShan 2280 V2 Kunpeng 920, 24-core socket $\times$ 4, 2.6 GHz, GCC version 9.4.0
 \end{itemize}
 …
 \paragraph{glibc (\textsf{glc})}
 \cite{glibc} is the default gcc thread-safe allocator.
+\cite{glibc} is the default glibc thread-safe allocator.
 \\
 \textbf{Version:} Ubuntu GLIBC 2.31-0ubuntu9.7 2.31\\
 …
 \paragraph{hoard (\textsf{hrd})}
 \cite{hoard} is a thread-safe allocator that is multi-threaded and using a heap layer framework. It has per-thread heaps that have thread-local free-lists, and a global shared heap.
+\cite{hoard} is a thread-safe allocator that is multi-threaded and uses a heap layer framework. It has per-thread heaps that have thread-local free-lists, and a global shared heap.
 \\
 \textbf{Version:} 3.13\\
 …
 \paragraph{tbb malloc (\textsf{tbb})}
 \cite{tbbmalloc} is a thread-safe allocator that is multi-threaded and uses private heap for each thread.
+\cite{tbbmalloc} is a thread-safe allocator that is multi-threaded and uses a private heap for each thread.
 Each private-heap has multiple bins of different sizes. Each bin contains free regions of the same size.
 \\
 …
 \section{Experiments}
 The each micro-benchmark is configured and run with each of the allocators,
 The less time an allocator takes to complete a benchmark the better, so lower in the graphs is better.
+Each micro-benchmark is configured and run with each of the allocators,
+The less time an allocator takes to complete a benchmark the better so lower in the graphs is better, except for the Memory micro-benchmark graphs.
 All graphs use log scale on the Y-axis, except for the Memory micro-benchmark (see \VRef{s:MemoryMicroBenchmark}).
 …
 Second is the low-performer group, which includes the rest of the memory allocators.
 These memory allocators have significant program-induced passive false-sharing, where \textsf{hrd}'s is the worst performing allocator.
+All of the allocator's in this group are sharing heaps among threads at some level.
+Interestingly, allocators such as \textsf{hrd} and \textsf{glc} performed well in micro-benchmark cache thrash (see \VRef{sec:cache-thrash-perf}).
+But, these allocators are among the low performers in the cache scratch.
+It suggests these allocators do not actively produce false-sharing but preserve program-induced passive false sharing.
+All of the allocators in this group are sharing heaps among threads at some level.
+Interestingly, allocators such as \textsf{hrd} and \textsf{glc} performed well in micro-benchmark cache thrash (see \VRef{sec:cache-thrash-perf}), but, these allocators are among the low performers in the cache scratch.
+It suggests these allocators do not actively produce false-sharing, but preserve program-induced passive false sharing.
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

doc/theses/mubeen_zulfiqar_MMath/uw-ethesis-frontpgs.tex

-              r015925a
+              re5d9274
         \vspace*{1.0cm}
         {\Huge\bf \CFA Memory Allocation}
+        {\Huge\bf High-Performance Concurrent Memory Allocation}
         \vspace*{1.0cm}
 …
 % D E C L A R A T I O N   P A G E
 % -------------------------------
   % The following is a sample Delaration Page as provided by the GSO
+  % The following is a sample Declaration Page as provided by the GSO
   % December 13th, 2006.  It is designed for an electronic thesis.
  \begin{center}\textbf{Author's Declaration}\end{center}
 …
 The goal of this thesis is to build a low-latency memory allocator for both kernel and user multi-threaded systems, which is competitive with the best current memory allocators, while extending the feature set of existing and new allocator routines.
 A new llheap memory-allocator is created that achieves all of these goals, while maintaining and managing sticky allocation properties for zero-fill and alignment allocations without a performance loss.
+A new llheap memory-allocator is created that achieves all of these goals, while maintaining and managing sticky allocation properties for zero-filled and aligned allocations without a performance loss.
 Hence, it becomes possible to use @realloc@ frequently as a safe operation, rather than just occasionally, because it preserves sticky properties when enlarging storage requests.
 Furthermore, the ability to query sticky properties and information allows programmers to write safer programs, as it is possible to dynamically match allocation styles from unknown library routines that return allocations.
 The C allocation API is also extended with @resize@, advanced @realloc@, @aalloc@, @amemalign@, and @cmemalign@ so programmers do not make mistakes writing theses useful allocation operations.
 llheap is embedded into the \uC and \CFA runtime systems, both of which have user-level threading.
 The ability to use \CFA's advanced type-system (and possibly \CC's too) to have one allocation routine with completely orthogonal sticky properties shows how far the allocation API can be pushed, which increases safety and greatly simplifies programmer's use of dynamic allocation.
+The ability to use \CFA's advanced type-system (and possibly \CC's too) to combine advanced memory operations into one allocation routine using named arguments shows how far the allocation API can be pushed, which increases safety and greatly simplifies programmer's use of dynamic allocation.
 The llheap allocator also provides comprehensive statistics for all allocation operations, which are invaluable in understanding and debugging a program's dynamic behaviour.
 No other memory allocator examined in the thesis provides comprehensive statistics gathering.
 As well, llheap provides a debugging mode where allocations are checked, along with internal pre/post conditions and invariants, is extremely useful, especially for students.
+No other memory allocator examined in the thesis provides such comprehensive statistics gathering.
+As well, llheap provides a debugging mode where allocations are checked with internal pre/post conditions and invariants. It is extremely useful, especially for students.
 While not as powerful as the @valgrind@ interpreter, a large number of allocations mistakes are detected.
 Finally, contention-free statistics gathering and debugging have a low enough cost to be used in production code.
 A micro-benchmark test-suite is started for comparing allocators, rather than relying on a suite of arbitrary programs, has been an interesting challenge.
+A micro-benchmark test-suite is started for comparing allocators, rather than relying on a suite of arbitrary programs. It has been an interesting challenge.
 These micro-benchmarks have adjustment knobs to simulate allocation patterns hard-coded into arbitrary test programs.
 Existing memory allocators, glibc, dlmalloc, hoard, jemalloc, ptmalloc3, rpmalloc, tbmalloc and the new allocator llheap are all compared using the new micro-benchmark test-suite.
+Existing memory allocators, glibc, dlmalloc, hoard, jemalloc, ptmalloc3, rpmalloc, tbmalloc, and the new allocator llheap are all compared using the new micro-benchmark test-suite.
 \cleardoublepage
 …
 I would like to thank all the people who made this thesis possible.
 I would like to acknowledge Peter A. Buhr for his assistance and support throughtout the process.
+I would like to acknowledge Peter A. Buhr for his assistance and support throughout the process.
 It would have been impossible without him.
+I would like to acknowledge Gregor Richards and Trevor Brown for reading my thesis quickly and giving me great feedback on my work.
 Also, I would say thanks to my team members at PLG especially Thierry, Michael, and Andrew for their input.
+Finally, a special thank you to Huawei Canada for funding this work.
 \end{center}
 \cleardoublepage
 …
 % L I S T   O F   T A B L E S
 % ---------------------------
 \addcontentsline{toc}{chapter}{List of Tables}
 \listoftables
 \cleardoublepage
 \phantomsection         % allows hyperref to link to the correct page
+% \addcontentsline{toc}{chapter}{List of Tables}
+% \listoftables
+% \cleardoublepage
+% \phantomsection               % allows hyperref to link to the correct page
 % Change page numbering back to Arabic numerals

doc/theses/mubeen_zulfiqar_MMath/uw-ethesis.tex

r015925a	re5d9274
106	106	pdffitwindow=false, % window fit to page when opened
107	107	pdfstartview={FitH}, % fits the width of the page to the window
108		pdftitle={~~Cforall~~ Memory Allocation}, % title: CHANGE THIS TEXT!
	108	pdftitle={High-Performance Concurrent Memory Allocation}, % title: CHANGE THIS TEXT!
109	109	pdfauthor={Mubeen Zulfiqar}, % author: CHANGE THIS TEXT! and uncomment this line
110	110	pdfsubject={Cforall}, % subject: CHANGE THIS TEXT! and uncomment this line

Context Navigation

Legend:

doc/theses/mubeen_zulfiqar_MMath/allocator.tex

doc/theses/mubeen_zulfiqar_MMath/background.tex

doc/theses/mubeen_zulfiqar_MMath/benchmarks.tex

doc/theses/mubeen_zulfiqar_MMath/conclusion.tex

doc/theses/mubeen_zulfiqar_MMath/figures/Header.fig

doc/theses/mubeen_zulfiqar_MMath/figures/MultipleHeapsNoOwnership.fig

doc/theses/mubeen_zulfiqar_MMath/figures/MultipleHeapsOwnership.fig

doc/theses/mubeen_zulfiqar_MMath/figures/PerThreadHeap.fig

doc/theses/mubeen_zulfiqar_MMath/figures/SharedHeaps.fig

doc/theses/mubeen_zulfiqar_MMath/figures/SingleHeap.fig

doc/theses/mubeen_zulfiqar_MMath/figures/UserKernelHeaps.fig

doc/theses/mubeen_zulfiqar_MMath/intro.tex

doc/theses/mubeen_zulfiqar_MMath/performance.tex

doc/theses/mubeen_zulfiqar_MMath/uw-ethesis-frontpgs.tex

doc/theses/mubeen_zulfiqar_MMath/uw-ethesis.tex

Download in other formats: