source: doc/theses/mubeen_zulfiqar_MMath/conclusion.tex @ cec2551

ADTast-experimental
Last change on this file since cec2551 was 29d8c02, checked in by m3zulfiq <m3zulfiq@…>, 2 years ago

made corrections in thesis as per feedback from the readers

  • Property mode set to 100644
File size: 3.9 KB
Line 
1\chapter{Conclusion}
2
3% \noindent
4% ====================
5%
6% Writing Points:
7% \begin{itemize}
8% \item
9% Summarize u-benchmark suite.
10% \item
11% Summarize @uHeapLmmm@.
12% \item
13% Make recommendations on memory allocator design.
14% \end{itemize}
15%
16% \noindent
17% ====================
18
19The 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.
20The new llheap memory-allocator achieves all of these goals, while maintaining and managing sticky allocation information without a performance loss.
21Hence, it becomes possible to use @realloc@ frequently as a safe operation, rather than just occasionally.
22Furthermore, 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.
23
24Extending the C allocation API with @resize@, advanced @realloc@, @aalloc@, @amemalign@, and @cmemalign@ means programmers do not have to do these useful allocation operations themselves.
25The 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.
26
27Providing comprehensive statistics for all allocation operations is invaluable in understanding and debugging a program's dynamic behaviour.
28No other memory allocator provides such comprehensive statistics gathering.
29This capability was used extensively during the development of llheap to verify its behaviour.
30As well, providing a debugging mode where allocations are checked, along with internal pre/post conditions and invariants, is extremely useful, especially for students.
31While not as powerful as the @valgrind@ interpreter, a large number of allocation mistakes are detected.
32Finally, contention-free statistics gathering and debugging have a low enough cost to be used in production code.
33
34The ability to compile llheap with static/dynamic linking and optional statistics/debugging provides programers with multiple mechanisms to balance performance and safety.
35These allocator versions are easy to use because they can be linked to an application without recompilation.
36
37Starting a micro-benchmark test-suite for comparing allocators, rather than relying on a suite of arbitrary programs, has been an interesting challenge.
38The current micro-benchmarks allow some understanding of allocator implementation properties without actually looking at the implementation.
39For example, the memory micro-benchmark quickly identified how several of the allocators work at the global level.
40It was not possible to show how the micro-benchmarks adjustment knobs were used to tune to an interesting test point.
41Many graphs were created and discarded until a few were selected for the thesis.
42
43
44\section{Future Work}
45
46A careful walk-though of the allocator fastpath should yield additional optimizations for a slight performance gain.
47In particular, analysing the implementation of rpmalloc, which is often the fastest allocator,
48
49The micro-benchmark project requires more testing and analysis.
50Additional allocation patterns are needed to extract meaningful information about allocators, and within allocation patterns, what are the most useful tuning knobs.
51Also, identifying ways to visualize the results of the micro-benchmarks is a work in progress.
52
53After llheap is made available on GitHub, interacting with its users to locate problems and improvements will make llbench a more robust memory allocator.
54As well, feedback from the \uC and \CFA projects, which have adopted llheap for their memory allocator, will provide additional information.
Note: See TracBrowser for help on using the repository browser.