Changeset 73a57af2

Apr 28, 2022, 1:02:13 PM (2 years ago)
m3zulfiq <m3zulfiq@…>
ADT, ast-experimental, master, pthread-emulation, qualifiedEnum

added abstract and acknowledge

1 edited


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

    r45200b67 r73a57af2  
    131 This is the abstract.
     131Memory management takes a sequence of program generated allocation/deallocation requests and attempts to satisfy them within a fixed-sized block of memory while minimizing the total amount of memory used.
     132A general-purpose dynamic-allocation algorithm cannot anticipate future allocation requests so its output is rarely optimal.
     133However, memory allocators do take advantage of regularities in allocation patterns for typical programs to produce excellent results, both in time and space (similar to LRU paging).
     134In general, allocators use a number of similar techniques, each optimizing specific allocation patterns.
     135Nevertheless, memory allocators are a series of compromises, occasionally with some static or dynamic tuning parameters to optimize specific program-request patterns.
     137The 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.
     138A 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.
     139Hence, it becomes possible to use @realloc@ frequently as a safe operation, rather than just occasionally, because it preserves sticky properties when enlarging storage requests.
     140Furthermore, 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.
     141The 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.
     142llheap is embedded into the \uC and \CFA runtime systems, both of which have user-level threading.
     143The 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.
     145The llheap allocator also provides comprehensive statistics for all allocation operations, which are invaluable in understanding and debugging a program's dynamic behaviour.
     146No other memory allocator examined in the thesis provides comprehensive statistics gathering.
     147As well, llheap provides a debugging mode where allocations are checked, along with internal pre/post conditions and invariants, is extremely useful, especially for students.
     148While not as powerful as the @valgrind@ interpreter, a large number of allocations mistakes are detected.
     149Finally, contention-free statistics gathering and debugging have a low enough cost to be used in production code.
     151A micro-benchmark test-suite is started for comparing allocators, rather than relying on a suite of arbitrary programs, has been an interesting challenge.
     152These micro-benchmarks have adjustment knobs to simulate allocation patterns hard-coded into arbitrary test programs.
     153Existing memory allocators, glibc, dlmalloc, hoard, jemalloc, ptmalloc3, rpmalloc, tbmalloc and the new allocator llheap are all compared using the new micro-benchmark test-suite.
    136157% -------------------------------
    138 \begin{center}\textbf{Acknowledgements}\end{center}
    140 I would like to thank all the little people who made this thesis possible.
     162I would like to thank all the people who made this thesis possible.
     164I would like to acknowledge Peter A. Buhr for his assistance and support throughtout the process.
     165It would have been impossible without him.
     167Also, I would say thanks to my team members at PLG especially Thierry, Michael, and Andrew for their input.
Note: See TracChangeset for help on using the changeset viewer.