added stable version of the document

docs/FutureTasks/docs.org

@@ -9,18 +9,19 @@ and will then expand into 2 potential paths:
 
 - Cheri RISCV to prevent using the TLB.
 - Allocator evaluation based on stripping instruction
-  calls for larger allocators like Jemalloc.
+  calls for larger allocators like Jemalloc\cite{noauthor_jemalloc_nodate}.
 
 
 ** 1. Current expirement: FAT pointer based range addresses
 #+NAME:   fig:FPBRA
+#+CAPTION: FAT pointer implementation with Huge pages against a standard malloc allocator.
 [[./HighOverviewArchitecture.drawio.png]]
 
 The objective of this expirement was to ensure we can use the CHERI bounds as
 tracking mechanism of allocations instead of using multiple TLB entries. Using
-this approach we can use a single Huge page entry with bounds to ensure that
+this approach we can use a single Huge page\cite{navarro_practical_nodate} entry with bounds to ensure that
 the bounds (Which is the top and base address) can be extracted from the
-pointer using the Cheri compressed bounds mechanism. We implemented a simple
+pointer using the Cheri compressed bounds\cite{woodruff_cheri_2019} mechanism. We implemented a simple
 allocator which uses this technique with a basic malloc and free.
 
 *** Objectives 
@@ -38,7 +39,7 @@ allocator which uses this technique with a basic malloc and free.
   utilization?
   
 *** Hardware
-- ARM morello (Huge page size 1GB used)
+- ARM morello\cite{noauthor_department_nodate} (Huge page size 1GB used)
 
 *** Evaluation
     We conducted tests of the FAT Pointer-based range addresses against Jemalloc,
@@ -65,12 +66,13 @@ performance in more practical, real-world scenarios.
 ** 2. Cheri RISCV to prevent using the TLB
 
 #+attr_latex: :width 200px
+#+CAPTION: FAT pointer implementation with RISCV CHERI Toooba to strip the requirement of requiring a TLB.  
 #+NAME: fig:RFPBRA
 [[./MainOverview.png]]
 
 In the current ARM Morello setup, address
 translations rely on the TLB. The future approach
-on RISC-V Tooba involves storing the offset directly within the pointer.
+on RISC-V Tooba\cite{noauthor_ctsrd-cheritoooba_nodate} involves storing the offset directly within the pointer.
 This is possible due to CHERI’s capability model, which supports
 fine-grained memory protection and can encode bounds within pointers.
 Utilizing Bounds in CHERI for Block-Based Allocation:
@@ -92,54 +94,186 @@ and improving performance, especially for frequent memory operations.
 ** 3. Allocator evaluation based on stripping instruction calls for larger allocators
 
 #+NAME: fig:MEMALLOC
+#+CAPTION: Deprecating the use of THP with CHERI bound aware embedded mmap. 
 [[./memory_allocator.drawio.png]]
 
-*** Box 1
+*** Box 1 (Transparent huge pages)
+#+BEGIN_COMMENT
 The diagram above mentions 3 particular implementations. The first box which is the
 standard THP(Transparent huge pages) utilised by modern allocators. THP initially
 emphasises on doing smalled allocations and as the number of allocations grows
 uses a technique which groups all smaller allocations together and when done
 converts them into a large page of size 4mb in allocators such as jemalloc.
+#+END_COMMENT
 
+The diagram [[fig:MEMALLOC]] highlights three specific implementations, the
+first of which is the standard Transparent Huge Pages (THP)
+mechanism employed by modern memory allocators. THP initially
+focuses on handling smaller memory allocations. As the volume
+of allocations increases, it employs a strategy that consolidates
+these smaller allocations into contiguous memory regions.
+Once aggregated, these regions are subsequently converted
+into larger memory pages, typically of size 4MB, as seen
+in allocators like jemalloc. This approach optimizes memory
+management by reducing fragmentation and improving performance
+through the use of larger page sizes.
+
+#+BEGIN_COMMENT
 This approach does incur addtional operations such as grouping smaller allocations
 chaging the TLB entries (Adding more oppurtunity for TLB misses). Only once the
 huge page is created the TLB misses are reduced.
+#+END_COMMENT
+This approach, however, introduces additional
+overhead, including the operations required to consolidate
+smaller allocations and modify Translation Lookaside Buffer (TLB)
+entries. These modifications can initially increase the
+likelihood of TLB misses, as the process of grouping and
+reorganizing memory allocations temporarily disrupts the
+efficiency of TLB utilization. It is only after the
+successful creation of the huge page that the benefits
+materialize, leading to a reduction in TLB misses due
+to the improved alignment of memory access patterns with
+the larger page size.
 
-*** Box 2
+*** Box 2 (Our current implementation)
+#+BEGIN_COMMENT
 Box 2 which refers to our current implementation always pre-allocates huge pages
 and untilises CHERI bounds to track each allocation inside the huge page. Allowing
 a single entry with the combination of bounds to provide block based behavoir in
 physically contigous memory while ensuring a pointer can only access a regoin
 within it's defined bounds.
+#+END_COMMENT
 
+Box 2 outlines the current implementation, which involves the
+pre-allocation of huge pages and leverages CHERI
+(Capability Hardware Enhanced RISC Instructions) bounds
+to meticulously track each allocation within these pages.
+This approach enables a single TLB entry, combined with
+the precise bounds defined by CHERI capabilities, to
+facilitate block-based memory management within physically
+contiguous regions. By enforcing strict bounds on pointers,
+the system ensures that each pointer can only access memory
+within its explicitly defined region.
+
+#+BEGIN_COMMENT
 Another aspect to note is that the bounds can be of a dynamic size when defined. This is
 in contrast to defining multiple page entries which need to be fixed sizes which means
 they always incur multiple entries. In the current approach when the huge page size is
 hit a new one is created. The limitaton of this is appraoch being we are limited to the
 huge page set by the processor implementation (In our case the CHERI ARM v8.1).
+#+END_COMMENT
 
-*** Box 3
+Another critical aspect of this implementation is the
+ability to define bounds of dynamic sizes, which stands
+in contrast to traditional approaches that rely on
+fixed-size page entries. Fixed-size entries inherently
+require multiple TLB entries, regardless of the actual
+memory usage, leading to inefficiencies. In the current
+approach, when the allocated memory within a huge page
+reaches its capacity, a new huge page is allocated.
+However, a notable limitation of this method is its
+dependence on the maximum huge page size supported by
+the underlying processor architecture. In this case,
+the system is constrained by the huge page size defined
+by the CHERI-enhanced ARM v8.1\cite{noauthor_arm_nodate} architecture. While this
+approach offers flexibility in memory allocation and
+reduces the need for multiple TLB entries, it is
+ultimately bounded by the hardware's architectural specifications.
+
+*** Box 3 (RISC-V implementation)
+#+BEGIN_COMMENT
 The 3rd box specifies an alternate appraoch by not using huge pages and required
 memory is not required to be physically contigous. In this approach the pointer
 stores all the metadata to the translation from virtual to physical addresses.
+#+END_COMMENT
 
-*** Building up from the work of Box 2 and Box 3
+The third approach, as outlined in Box 3, deviates from the
+use of huge pages and does not require memory to be
+physically contiguous. In this model, each pointer
+is designed to store comprehensive metadata at the pointer necessary
+for the translation from virtual to physical addresses.
+This metadata enables the system to manage memory allocations
+without the constraints of physical contiguity, thereby
+offering greater flexibility in memory utilization.
+By embedding translation information directly within the
+pointers, this approach eliminates the need for large,
+contiguous memory regions and allows for more granular
+and dynamic memory management.
+
+*** Building up from the work of Box 2 and Box 3 (Side effects we can strip away)
+#+BEGIN_COMMENT
 Box 2 and 3 from a high overview there is only minor difference which can be noted
 which is 1 uses huge pages and other does not. Both approaches can strip down the
 number intructions needed in modern allocators (Stripping away the need transitioning
 from smaller to larger pages). This document is yet to give an exact breakdown.
+#+END_COMMENT
 
+From a high-level perspective, the primary distinction between
+Box 2 and Box 3 lies in the use of huge pages in the former
+and their absence in the latter. Both approaches share
+the common advantage of reducing the number of instructions
+required in modern memory allocators by eliminating the
+need for transitioning between smaller and larger pages.
+This simplification streamlines memory management processes.
+However, this document has not yet provided a detailed breakdown
+or quantitative analysis of the specific performance implications
+or trade-offs.
+
+#+BEGIN_COMMENT
 As seen to the right of the diagram is a sample snippet of TC malloc from the paper
 (Beyond malloc efficiency to fleet allocators). This whole span function would not
 be required in our approach. The other benefit being easier get the approach by
 getting mmap embedded inside the allocator.
+#+END_COMMENT
+
+As illustrated to the right of the diagram, a sample snippet of
+TC malloc from the paper Beyond malloc Efficiency to Fleet
+Efficiency is provided. In the proposed approach, the entire
+span function, which is essential in TC malloc, would become
+unnecessary. Additionally, the approach offers the advantage
+of simplifying memory management by integrating mmap directly
+within the allocator. This integration eliminates the need for
+separate mechanisms to handle memory mapping.
 
 *** Evaluation:
+#+BEGIN_COMMENT
 - Amount of instructions that can be stripped away from the page aware
   memory allocator.
 - Comparing memory allocator with wall clock run time with the modified mmap and without the modified mmap.
 - CHERI purecap does incur additional instruction such as bound checks. Does this approach as a whole
   reduce the number of instructions as whole (Comparing CHERIpurecap instructions with memory allocator
   emitted vs regular ARMv8 clang program with the same allocator). 
+#+END_COMMENT
 
+- The number of instructions that can be eliminated from a
+  page-aware memory allocator by adopting the proposed approach.
+
+- A comparative analysis of the memory allocator's performance
+  using wall-clock runtime measurements, both with and without
+  the modified mmap implementation.
+
+- While CHERI Purecap introduces additional instructions, such
+  as bounds checks, the overall approach aims to determine
+  whether it reduces the total number of instructions when
+  compared to a traditional ARMv8 Clang program using the
+  same allocator. This involves evaluating the trade-offs
+  between the overhead of CHERI-specific instructions and
+  the potential reductions in allocator-emitted instructions.
+
+** Current tasks on hand
+1. To port over all chapters written to a
+   EuroSys Conferenece document and send over the
+   to the supervisory team for a review.
+   - This will then get send over to Jeremy
+     for an external review.
+   - Expands to a talk in the University
+     of Glasgow seminar.
+   - Concurrent suggestions of the Eurosys
+     submission till may.
+2. Work on allocator evaluation based on stripping instruction calls for
+   larger allocators (Expirement agreed in the meeting). 
+3. Write to Cambridge a proposal for using the RISC-V expirement (2 weeks).
+    
+\bibliographystyle{IEEEtran}
+\bibliography{FuturePlan.bib}