source: doc/theses/mubeen_zulfiqar_MMath/conclusion.tex @ 159460f

\chapter{Conclusion}

% \noindent
% ====================
% 
% Writing Points:
% \begin{itemize}
% \item
% Summarize u-benchmark suite.
% \item
% Summarize @uHeapLmmm@.
% \item
% Make recommendations on memory allocator design.
% \end{itemize}
% 
% \noindent
% ====================

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 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 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 allocation mistakes are detected.
Finally, contention-free statistics gathering and debugging have a low enough cost to be used in production code.

The ability to compile llheap with static/dynamic linking and optional statistics/debugging provides programers with multiple mechanisms to balance performance and safety.
These allocator versions are easy to use because they can be linked to an application without recompilation.

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 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.
Many graphs were created and discarded until a few were selected for the thesis.


\section{Future Work}

A careful walk-though of the allocator fastpath should yield additional optimizations for a slight performance gain.
In particular, analysing the implementation of rpmalloc, which is often the fastest allocator,

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 information.