FAT-Allocator/docs/EuroSys/Paper/paper.tex

%%
%% This is file `sample-sigconf-authordraft.tex',
%% generated with the docstrip utility.
%%
%% The original source files were:
%%
%% samples.dtx  (with options: `all,proceedings,bibtex,authordraft')
%%
%% IMPORTANT NOTICE:
%%
%% For the copyright see the source file.
%%
%% Any modified versions of this file must be renamed
%% with new filenames distinct from sample-sigconf-authordraft.tex.
%%
%% For distribution of the original source see the terms
%% for copying and modification in the file samples.dtx.
%%
%% This generated file may be distributed as long as the
%% original source files, as listed above, are part of the
%% same distribution. (The sources need not necessarily be
%% in the same archive or directory.)
%%
%%
%% Commands for TeXCount
%TC:macro ~\cite [option:text,text]
%TC:macro ~\citep [option:text,text]
%TC:macro ~\citet [option:text,text]
%TC:envir table 0 1
%TC:envir table* 0 1
%TC:envir tabular [ignore] word
%TC:envir displaymath 0 word
%TC:envir math 0 word
%TC:envir comment 0 0
%%
%%
%% The first command in your LaTeX source must be the \documentclass
%% command.
%%
%% For submission and review of your manuscript please change the
%% command to \documentclass[manuscript, screen, review]{acmart}.
%%
%% When submitting camera ready or to TAPS, please change the command
%% to \documentclass[sigconf]{acmart} or whichever template is required
%% for your publication.
%%
%%
\documentclass[sigconf,authordraft]{acmart}
\usepackage{listings}
\usepackage{algorithm}
\usepackage{algpseudocode}
\usepackage{amsmath}

\usepackage{lipsum}
\usepackage{stfloats}
\usepackage{grffile}
\usepackage{hyperref}

\usepackage{multicol}
\usepackage{graphicx}
\usepackage{subcaption}
\usepackage{caption}
\usepackage{graphicx}
\usepackage{natbib}

\lstset{basicstyle=\small\ttfamily,columns=fullflexible}

%%
%% \BibTeX command to typeset BibTeX logo in the docs
\AtBeginDocument{%
  \providecommand\BibTeX{{%
    Bib\TeX}}}

%% Rights management information.  This information is sent to you
%% when you complete the rights form.  These commands have SAMPLE
%% values in them; it is your responsibility as an author to replace
%% the commands and values with those provided to you when you
%% complete the rights form.
\setcopyright{acmlicensed}
\copyrightyear{2018}
\acmYear{2018}
\acmDOI{XXXXXXX.XXXXXXX}

%% These commands are for a PROCEEDINGS abstract or paper.
\acmConference[Conference acronym 'XX]{Make sure to enter the correct
  conference title from your rights confirmation emai}{June 03--05,
  2018}{Woodstock, NY}
%%
%%  Uncomment \acmBooktitle if the title of the proceedings is different
%%  from ``Proceedings of ...''!
%%
%%\acmBooktitle{Woodstock '18: ACM Symposium on Neural Gaze Detection,
%%  June 03--05, 2018, Woodstock, NY}
\acmISBN{978-1-4503-XXXX-X/18/06}


%%
%% Submission ID.
%% Use this when submitting an article to a sponsored event. You'll
%% receive a unique submission ID from the organizers
%% of the event, and this ID should be used as the parameter to this command.
%%\acmSubmissionID{123-A56-BU3}

%%
%% For managing citations, it is recommended to use bibliography
%% files in BibTeX format.
%%
%% You can then either use BibTeX with the ACM-Reference-Format style,
%% or BibLaTeX with the acmnumeric or acmauthoryear sytles, that include
%% support for advanced citation of software artefact from the
%% biblatex-software package, also separately available on CTAN.
%%
%% Look at the sample-*-biblatex.tex files for templates showcasing
%% the biblatex styles.
%%

%%
%% The majority of ACM publications use numbered citations and
%% references.  The command ~\citestyle{authoryear} switches to the
%% "author year" style.
%%
%% If you are preparing content for an event
%% sponsored by ACM SIGGRAPH, you must use the "author year" style of
%% citations and references.
%% Uncommenting
%% the next command will enable that style.
%%~\citestyle{acmauthoryear}


%%
%% end of the preamble, start of the body of the document source.
\begin{document}

%%
%% The "title" commanSd has an optional parameter,
%% allowing the author to define a "short title" to be used in page headers.
\title{FAT allocator}

%%
%% The "author" command and its associated commands are used to define
%% the authors and their affiliations.
%% Of note is the shared affiliation of the first two authors, and the
%% "authornote" and "authornotemark" commands
%% used to denote shared contribution to the research.
\author{Akilan Selvacoumar}
% \authornote{Both authors contributed equally to this research.}
% \email{as251@hw.ac.uk}
% \orcid{1234-5678-9012}
% \author{G.K.M. Tobin}
\authornotemark[1]
\email{as251@hw.ac.uk}
\affiliation{%
  \institution{Heriot Watt}
  \city{Edinburgh}
  \state{Scotland}
  \country{United Kingdom}
}

% \author{Lars Th{\o}rv{\"a}ld}
% \affiliation{%
%   \institution{The Th{\o}rv{\"a}ld Group}
%   \city{Hekla}
%   \country{Iceland}}
% \email{larst@affiliation.org}

% \author{Valerie B\'eranger}
% \affiliation{%
%   \institution{Inria Paris-Rocquencourt}
%   \city{Rocquencourt}
%   \country{France}
% }

% \author{Aparna Patel}
% \affiliation{%
%  \institution{Rajiv Gandhi University}
%  \city{Doimukh}
%  \state{Arunachal Pradesh}
%  \country{India}}

% \author{Huifen Chan}
% \affiliation{%
%   \institution{Tsinghua University}
%   \city{Haidian Qu}
%   \state{Beijing Shi}
%   \country{China}}

% \author{Charles Palmer}
% \affiliation{%
%   \institution{Palmer Research Laboratories}
%   \city{San Antonio}
%   \state{Texas}
%   \country{USA}}
% \email{cpalmer@prl.com}

% \author{John Smith}
% \affiliation{%
%   \institution{The Th{\o}rv{\"a}ld Group}
%   \city{Hekla}
%   \country{Iceland}}
% \email{jsmith@affiliation.org}

% \author{Julius P. Kumquat}
% \affiliation{%
%   \institution{The Kumquat Consortium}
%   \city{New York}
%   \country{USA}}
% \email{jpkumquat@consortium.net}

%%
%% By default, the full list of authors will be used in the page
%% headers. Often, this list is too long, and will overlap
%% other information printed in the page headers. This command allows
%% the author to define a more concise list
%% of authors' names for this purpose.
% \renewcommand{\shortauthors}{Trovato et al.}

%%
%% The abstract is a short summary of the work to be presented in the
%% article.
\begin{abstract}
  % The increasing disparity between application workloads and the capacity of s (TLB)
  % has prompted researchers to explore innovative solutions to mitigate this gap. One such approach involves
  % leveraging physically contiguous memory and the use of huge pages to optimize TLB utilization. Huge pages,
  % which group multiple smaller pages into larger ones, reduce TLB miss rates by decreasing the number of entries
  % required in the TLB, thus improving overall performance. Concurrently, advancements in hardware-level system
  % security, exemplified by the Capability Hardware Enhanced RISC Instructions (CHERI) architecture, offer
  % additional opportunities for improving memory management and security.

  % CHERI introduces capability-based addressing, a novel approach that enhances system security by
  % associating capabilities with memory pointers. These capabilities restrict access to memory regions,
  % thereby fortifying the system against various security threats. Importantly, the mechanisms implemented in
  % CHERI for enforcing memory protection can also serve as accelerators for standard user-space memory allocators.
  % By leveraging capability-based addressing, memory allocators can efficiently manage memory resources, ensure
  % robust security measures are in place, and potentially enhance performance through the integration of huge pages,
  % further improving TLB efficiency and memory handling.

  % Through our evaluation using both micro and macro benchmarks,
  % we show that our allocator can reduce TLB misses by up to 90\%,
  % leading to substantial improvements in wall clock runtimes for memory-intensive
  % applications.

  % The increasing disparity between application workloads and the capacity of translation lookaside buffers (TLBs) has prompted researchers 
  % to explore solutions to mitigate the extra clock cycles incurred during a TLB miss. One such approach involves leveraging physically contiguous memory 
  % and the use of huge pages. Concurrently, advancements in hardware-level system security—exemplified by the Capability Hardware 
  % Enhanced RISC Instructions (CHERI) architecture—offer additional opportunities for improving TLB performance. CHERI introduces 
  % capability-based addressing, a novel approach that enhances system security by associating capabilities with memory pointers. By leveraging capability-based 
  % addressing, we introduce a memory allocator that can integrate block-based allocations within huge pages. Through our evaluation using both micro and macro benchmarks, we show that 
  % our allocator can reduce TLB misses by up to 90\%, leading to improvements in wall clock runtimes for memory-intensive applications.

  % The increasing gap between workload memory requirements and the capacity of translation lookaside buffers (TLBs) in hardware cache management of modern processors means that TLB misses
  % are more frequent, costing additional clock cycles and impacting runtime performance. One solution that has been explored is to use physically contiguous
  % memory in conjunction with huge pages.

  % The contribution is an alternative approach by exploiting capability-based addressing in the
  % CHERI architecture. This paper presents a new memory allocator called Fat Address Translations (FAT) which associates capabilities with memory pointers by integrating
  % block-based allocations within huge pages. When the FAT allocator is ran independently and embedded inside Jemalloc, it reduces by up to 99\% walking the TLB hierarchy. This leads to
  % decreasing runtimes for memory read and write intensive applications.
  % The FAT allocator when ran independently and embedded inside Jemalloc reduces walking the TLB hierarchy by upto 90\%, which leads to decreasing runtimes
  % for memory read and write intensive applications.

% The widening gap between application memory demands and the limited capacity of hardware Translation Lookaside Buffers (TLBs) 
% in modern processors leads to frequent TLB misses, incurring significant performance penalties due to additional clock cycles 
% spent on page table walks. A common mitigation strategy involves the use of physically contiguous memory and huge pages to 
% reduce TLB pressure.

% This paper introduces a solution that leverages capability-based addressing in the CHERI architecture with huge pages.
% We present Fat Address Translations (FAT), a memory allocator that embeds allocation metadata directly within 
% pointer capabilities and manages memory in block-based allocations within huge pages. By encoding allocation bounds in capabilities, 
% FAT enables more efficient pointer dereferencing and reduces reliance on smaller page table entry lookups. Our evaluation shows that FAT, 
% both as a standalone allocator and when integrated into Jemalloc, reduces TLB hierarchy walks by up to 99\% in contrast to standard system allocators and improves runtime performance for memory read intensive applications. 
% This demonstrates that capability-based addressing can repurposed to mitigate TLB pressure.
Modern processors increasingly suffer from Translation Lookaside Buffer (TLB) pressure, where frequent misses lead to costly page table walks and degraded performance. While huge pages can mitigate some of this overhead, 
allocator-level inefficiencies persist.

We present Fat Address Translations (FAT), a memory allocator for capability-aware architectures such as CHERI. FAT 
embeds allocation metadata directly within pointer capabilities and manages memory in block-based allocations inside 
huge pages, reducing reliance on page table lookups and enabling more efficient pointer dereferencing. Evaluation shows that 
FAT reduces TLB walks by up to 99\% and L2 TLB reads by 98\%. Runtime performance improves by up to 11\% in macro-benchmarks (e.g. XSBench), 1.8–4\% 
in Kmeans and Barnes, and 4\% in micro-benchmarks such as Memaccess, while Richards remains near baseline. These results demonstrate 
that capability-based addressing can be repurposed to mitigate TLB pressure, offering a scalable and efficient strategy for memory allocation 
in future capability-aware systems.
\end{abstract}

%%
%% The code below is generated by the tool at http://dl.acm.org/ccs.cfm.
%% Please copy and paste the code instead of the example below.
% %%
% \begin{CCSXML}
% <ccs2012>
%  <concept>
%   <concept_id>00000000.0000000.0000000</concept_id>
%   <concept_desc>Do Not Use This Code, Generate the Correct Terms for Your Paper</concept_desc>
%   <concept_significance>500</concept_significance>
%  </concept>
%  <concept>
%   <concept_id>00000000.00000000.00000000</concept_id>
%   <concept_desc>Do Not Use This Code, Generate the Correct Terms for Your Paper</concept_desc>
%   <concept_significance>300</concept_significance>
%  </concept>
%  <concept>
%   <concept_id>00000000.00000000.00000000</concept_id>
%   <concept_desc>Do Not Use This Code, Generate the Correct Terms for Your Paper</concept_desc>
%   <concept_significance>100</concept_significance>
%  </concept>
%  <concept>
%   <concept_id>00000000.00000000.00000000</concept_id>
%   <concept_desc>Do Not Use This Code, Generate the Correct Terms for Your Paper</concept_desc>
%   <concept_significance>100</concept_significance>
%  </concept>
% </ccs2012>
% \end{CCSXML}

% \ccsdesc[500]{Do Not Use This Code~Generate the Correct Terms for Your Paper}
% \ccsdesc[300]{Do Not Use This Code~Generate the Correct Terms for Your Paper}
% \ccsdesc{Do Not Use This Code~Generate the Correct Terms for Your Paper}
% \ccsdesc[100]{Do Not Use This Code~Generate the Correct Terms for Your Paper}

%%
%% Keywords. The author(s) should pick words that accurately describe
%% the work being presented. Separate the keywords with commas.
% \keywords{Do, Not, Us, This, Code, Put, the, Correct, Terms, for,
%   Your, Paper}
%% A "teaser" image appears between the author and affiliation
%% information and the body of the document, and typically spans the
%% page.
% \begin{teaserfigure}
%   \includegraphics[width=\textwidth]{sampleteaser}
%   \caption{Seattle Mariners at Spring Training, 2010.}
%   \Description{Enjoying the baseball game from the third-base
%   seats. Ichiro Suzuki preparing to bat.}
%   \label{fig:teaser}
% \end{teaserfigure}

% \received{20 February 2007}
% \received[revised]{12 March 2009}
% \received[accepted]{5 June 2009}

%%
%% This command processes the author and affiliation and title
%% information and builds the first part of the formatted document.
\maketitle

\section{Introduction}
% In the dynamic landscape of computing, the pursuit of optimal performance is a constant endeavor,
% especially as applications evolve to handle increasingly complex workloads.
% One critical aspect influencing performance is memory management, where efficient
% utilization of resources is paramount. s (TLBs) play a
% pivotal role in this regard, expediting memory access by storing recently accessed memory translations.
% However, as applications grow in size and complexity, the capacity of TLBs often struggles to
% keep pace, leading to performance bottlenecks~\cite{mittalsurvey2017}. To address this challenge, researchers have
% turned to innovative solutions, one of which involves harnessing the benefits of huge pages.
% Huge pages, also known as large pages, allow for the allocation of memory in significantly
% larger chunks compared to traditional small pages. By reducing the number of TLB entries
% needed to access a given amount of memory, huge pages offer a potential avenue for optimizing
% TLB utilization and thereby enhancing overall system performance.

% Simultaneously, advancements in hardware-level security, such as the Capability Hardware
% Enhanced RISC Instructions (CHERI) architecture, present additional opportunities for
% performance enhancement. CHERI's capability-based addressing approach not only strengthens
% system security by tightly controlling memory access but also provides avenues for
% accelerating memory management operations.

In computing, achieving high performance is an ongoing challenge, especially as
modern applications handle increasingly memory intensive workloads. 
% Performance referring to memory access rather than compute bound. 
Memory management is a key factor in reducing the time it takes to access a memory region. 
A Translation Lookaside Buffer (TLB) is a specialised cache in the memory management unit (MMU).
It reduces the time required to convert virtual addresses to physical addresses. When a program accesses
data in memory, the MMU first checks the TLB for a matching entry and avoids the slow process of
accessing the page tables situated in memory.
TLBs are crucial in speeding up memory access by caching recent
memory address translations. The TLB hierarchy~\cite{TLBHierarchy} comprises of a smaller, faster L1 TLB situated close to the processor core and a larger 
slightly slower L2 TLB, both of which are usually private to each core thereby reducing the latency associated with page table lookups. 
However, as applications grow more complex the TLBs often cannot keep up with the number of translation entries leading to more TLB misses which requires walking
the TLB hierarchy and this leads to performance slowdowns~\cite{mittal_survey_2017}.
To tackle this issue, researchers have explored new solutions, including the use of
huge pages~\cite{panwar_hawkeye_2019}.

Huge pages also known as large pages allow for the allocation of memory in significantly larger chunks
compared to traditional small pages which leads to fewer number of TLB entries needed to access a given amount
of memory. Huge pages offer a potential avenue for optimising TLBs which are used by reducing the number
of entries needed to map large memory regions. This not only decreases the frequency of
TLB misses but also lowers the overhead associated with address translation in regards to traversing the TLB cache 
hierarchy and therefore minimising these bottlenecks.
% huge pages can improve system performance in aspects such as speeding
% up memory-intensive applications, reducing latency in data access and enhancing throughput for
% workloads that rely heavily on large datasets.

% Ryad's comment:
% If the TLB's are linked to a core. Will they behave differently for multi-cores? and who manages this? I believe Cheri is not single-core.
% Did you cover this at some point in your work?
% Answer: The focus on this paper is on single core execution.

Simultaneously, advancements in hardware-level security, such as the Capability Hardware Enhanced RISC Instructions (CHERI)
~\cite{woodruff_cheri_2014} which are standard 64-bit pointers that are replaced with capabilities with 128-bit or 256-bit 
encoding scheme which consists of both the address and metadata. The metadata includes bounds, permissions and validity of the pointer
which forms a capability. This transformation of larger pointers enforces strict memory 
safety as capabilities prevent arbitrary pointer arithmetic and unauthorised memory access.
CHERI's capability-based addressing approach not
only strengthens system security by tightly controlling memory access but also opens avenues for optimising memory management
operations. By integrating CHERI's compressed encoded bounds~\cite{woodruff_cheri_2019} with the use of huge pages, one of the contribution is demonstrating that it is possible to track, manage
large and physically contiguous memory blocks without requiring numerous TLB entries. This combination reduces the TLB pressure by minimising the number of
entries required to map extensive memory regions thereby decreasing TLB misses and improving address translation performance.
Furthermore, this paper introduces the Fat Address Translations(FAT) allocator which accelerates memory-intensive tasks by reducing the overhead associated with managing non-contiguous
memory allocations by emulating block allocations on physically contiguous memory to reduce the TLB pressure. The contributions for the following paper are as follows:
\begin{itemize}
  \item \textbf{FAT Addresses Translations}: Introduces FAT that include memory bounds, allowing
  efficient tracking and management of physically contiguous memory regions (Section ~\ref{sec:FatPointerTranslations}).

  \item \textbf{CHERI's Capability-based Optimisation}: Demonstrates how CHERI's architecture can be
  used to optimise memory allocation by encoding memory bounds directly within pointers, reducing TLB reliance
   (Section ~\ref{sec:128bitCompressedBounds}).

  \item \textbf{Memory Allocation Algorithms (FAT allocator)}: Presents an algorithm for allocating, freeing
  physically contiguous memory , and integrating huge pages with CHERI's capability-based bounds for enhanced memory management
   (Section ~\ref{sec:MemoryAllocator}).

   \item \textbf{Modified Jemalloc Memory Mapping with FAT allocator}: Modification to Jemalloc with the FAT allocator to support physically contiguous 
   memory allocation using a block-based strategy with capability-based addressing (Section ~\ref{sec:JemallocFATAllocator}).
\end{itemize} 

Through evaluating micro and macro benchmarks the FAT allocator though the use of CHERI's capabilities and huge pages demonstrates the allocator's ability
to reduce TLB walks by up to 99\% which yields to improvements of wall clock runtimes by upto 11\% for memory-intensive
applications. While its impact on larger and computation-heavy workloads is less pronounced.
The proposed allocator shows strong potential for advancing memory management in scenarios requiring
high memory throughput by reducing the address translation overhead.

\section{Related work}
\label{sec:org0e192da}

\subsection{Huge Pages}
% A segment~\cite{basu_efficient_nodate} can be viewed as mapping between contiguous virtual
% memory and contiguous physical memory. The property of a
% segment allows it to be larger than a page. Direct Segment allows the user to set a single segment
% for an application. Two registers are added to mark the start
% and end of the segment. Any virtual address within this region
% can be translated by adding the fixed offset between the virtual
% and physical address.
Increasing TLB reach\cite{TLBReach} can be achieved by using larger page sizes such as huge pages~\cite{panwar_hawkeye_2019} which are common in modern computer systems.
The x86-64 architecture supports huge pages of 2 MB and 1 GB which are backed by OS mechanisms like Transparent Huge Pages (THP)~\cite{THP}
. However, available page sizes in x86-64 are limited, leading to internal fragmentation issues.

% Alternate segment technique
% - JayneelGandhi,ArkapravaBasu,MarkD.Hill,andMichaelM.Swift.2014.Efficientmemoryvirtualization:Reducing
For instance, allocating 1 MB with 4 KB base pages requires 256 PTEs (Page Table Entries) and in contrast using a 2 MB huge page would waste
half of the memory space. Some architectures offer more page size choices, such as Intel Itanium~\cite{IntelItanium} which
allows different areas of the address space to have their own page sizes. Itanium uses a hash page table to organise huge
pages and without significant changes to the conventional page table. It only helps reduce page walk overheads.
Huge page tunable base page size permits the OS to adjust the base page, but still faces internal fragmentation problems
with huge page recommending a base page size of no more than 16 KB. Shadow Superpage~\cite{Shadow_superpages} introduces a new translation level
in the memory controller to merge non-contiguous physical pages into a huge page in a shadow memory space by extending
TLB coverage. However, this approach requires all memory traffic to be translated again in the memory controller
resulting in additional latency for memory accesses.

\subsection{Direct Segment}
Early processors often used segments to manage virtual memory, where a segment~\cite{DirectSegment} essentially mapped contiguous
virtual memory to contiguous physical memory. Unlike pages which are relatively small, segments can be much
larger offering the potential for more efficient memory management.
This concept of segmentation has seen a resurgence in some modern approaches that aim to enhance
translation coverage by designating specific areas in the virtual address space.

This method allows programmers to explicitly define
a single segment for applications requiring significant memory. It introduces two new
registers to the system, which indicate the start and end of this segment.
Virtual addresses within this segment are translated by calculating
the offset from the virtual start address and applying this offset to the
physical start address. This straightforward method simplifies the translation
process for large memory areas but requires significant modifications to the
source code of applications.

\subsection{Redundant Memory Mapping (RMM)}
Redundant Memory Mappings (RMM)~\cite{karakostas_redundant_2015} enhance memory management by introducing an additional range table
that pre-allocates contiguous physical pages for large memory allocations thus creating ranges that
are both virtually and physically contiguous. This approach simplifies address translation
by adding ranges. RMM is similar to Direct Segment with the support of multiple
ranges and operates transparently to programmers. No source code modifications is required on the programmers
side. The range table which is separate from the conventional page table holds the mappings for these
large allocations. To determine which range an address belongs to, RMM compares the address
against all range boundaries. Since this process is computationally expensive hence it is therefore performed
only after an L1 TLB miss. To optimise this, RMM uses a Range TLB (RTLB) to quickly identify
if an address falls within any pre-allocated range. Range mapping works alongside the paging system by generating TLB entries on
TLB misses and still performs TLB lookups for each virtual address translation.
Unlike traditional segmentation mechanisms, range mapping activates the RTLB located with the last level TLB upon a miss. The hardware TLB miss
handler then searches the RTLB for the missed address. If found, generates a new
TLB entry with the physical address derived from the base virtual address and
range offset along with the permission bits. If the RTLB also misses, the system
defaults to a standard page walk while a range table walker simultaneously
loads the range into the RTLB on the background. This avoids delays for in-memory operations.
The RTLB functions as a fully associative search structure ensuring
that most last-level TLB misses are handled efficiently by range mapping which
reduces the need for costly page table walks.

\subsection{FlexPointer}
The key insight behind FlexPointer~\cite{chen_flexpointer_2023} is that large memory objects are relatively uncommon. This allows memory ranges to be constructed around
them and assigned unique identifiers. These range IDs are embedded within the unused bits of pointers, enabling direct indexing of the range 
TLB and simplifying its design. Since the range ID is unaffected by address generation, range lookups can occur earlier in the pipeline, 
concurrently with address computation. Simulation results show that FlexPointer significantly reduces L1 TLB misses and the need for page walks 
in a range of memory-intensive workloads. When compared with a traditional 4KB-page system, FlexPointer delivers an average performance improvement 
of 14\%, with peak gains of up to 2.8×, and introduces no performance regressions in less demanding scenarios.

% Ryad comment:
% Is this from reference 12?
% Does the whole section refer to reference 12?
% The whole section is reference 12


\subsection{CHERI}
\label{sec:orgbf2eaac}
% CHERI extends conventional processor
% Instruction-Set Architectures (ISAs) with architectural capabilities to enable fine-grained
% memory protection and highly scalable software compartmentalization. CHERI is a hybrid
% capability architecture that can combine capabilities with conventional MMU (Memory Management Unit) based systems.
% The contributions of CHERI include:
% \begin{itemize}
% \item ISA changes to introduce architectural capabilities.
% \item New microarchitecture proving that capabilities can be implemented efficiently in hardware, with support for
% efficient tagged memory to protect capabilities and compress capabilities to reduce memory overhead.
% \item A newly designed software construction model that uses capabilities to provide fine-grained memory protection
% and scalable software compartmentalization.
% \item Language and compiler extensions for using capabilities with C and C++.
% \item OS extensions to support fine-grained memory protection (spatial, referential, and (non-stack) temporal memory safety)
% and abstraction extensions for scalable software compartmentalization.
% \end{itemize}
CHERI extends conventional processor Instruction-Set Architectures (ISAs) 
with architectural capabilities to enable fine-grained memory protection 
and highly scalable software compartmentalisation. It is a hybrid capability 
architecture that can combine capabilities with conventional MMU (Memory Management Unit) 
based systems. The contributions of CHERI includes ISA changes to introduce architectural 
capabilities and is a new microarchitecture which shows that capabilities can be implemented efficiently in hardware.
CHERI provides support for efficient tagged memory to protect capabilities and compresses them to reduce memory overhead. 
The CHERI ecosystem provides language and compiler extensions for using capabilities with C and C++. An OS extensions is also 
provided to support fine-grained memory protection (including spatial, referential, and non-stack temporal memory safety) and abstraction extensions 
for scalable software compartmentalisation.

\subsection{CHERI CC}
CHERI CC(Concentrate Compressed Capabilities)~\cite{woodruff_cheri_2019} introduces a compression scheme for CHERI that aims to address the performance and compatibility challenges associated with 
capability pointers. Capability pointers enhance memory safety by embedding bounds and permissions directly 
within pointers. Traditional implementations of CHERI double their size leading in bounds to increased memory usage. CHERI CC
proposes a compression strategy that preserves security while reducing size and inefficiencies. Key contributions include a floating-point 
bound encoding technique with an internal exponent mechanism that offers greater precision for smaller objects and optimised space usage for larger ones.

\section{Fat Address Translations}
\label{sec:FatPointerTranslations}
Fat Address Translations (FAT) is our new memory allocator for CHERI. It uses the CHERI architecture to
bring about block-based allocations in physically contiguous memory. 
FAT leverages techniques like FlexPointer~\cite{chen_flexpointer_2023}, RMM~\cite{karakostas_redundant_2015} in context of introducing
a range table to store custom address translation memory ranges to 
reduce pressure on the TLB.  A key component 
in this implementation is the use of range addresses with CHERI CC~\cite{woodruff_cheri_2019}.

% Fat-pointer Address Translations, combined with the capabilities of the CHERI
% architecture, introduce robust memory safety and security features by incorporating additional metadata
% with memory pointers. Fat-pointer Address Translations enhanced architecture uses concepts such as FlexPointer~\cite{chen_flexpointer_2023},
% Range Memory Mapping (RMM)~\cite{karakostas_redundant_2015} to manage memory effectively.

% Range addresses play a pivotal role within the Fat Address Translations implementation, defining memory
% regions bounded by a starting address (Upper) and an ending address (Lower).
% These range addresses are encoded within FAT-pointers, allowing for precise
% control using CHERI CC~\cite{woodruff_cheri_2019} bounds over memory regions to reduce the number of TLB operations needed.

% The functionality of ranges encompasses several key aspects:
% \begin{itemize}
% \item \textbf{Creation of Physically Contiguous Memory Ranges}:
% By defining memory regions that are physically contiguous, systems can
% achieve optimal memory access patterns, enhancing performance and efficiency.
% \item \textbf{Encoding Ranges as Bounds to the Pointer}:
% Integrating range bounds directly into FAT-pointers enables the architecture
% to enforce memory access restrictions at the pointer level thus allowing
% tracking of memory ranges on a pointer level.
% \item \textbf{Instrumenting Block-Based Allocators with Physically Contiguous Memory}:
% The integration of range-based memory concepts into memory allocation systems, such as block-based
% allocators, facilitates the efficient management and utilization of physically contiguous memory blocks,
% mitigating issues related to memory fragmentation.
% \end{itemize}

% \begin{figure}[ht]ß
%   \centering
%   \includesvg[width=0.8\linewidth]{diagram/drawing.svg}
%   \caption{High overview architecture}
%   \label{fig:HighOverviewArchitecture}√
% \end{figure}

\begin{figure}[ht]
  \centering
  \includegraphics[width=0.8\linewidth]{diagram/drawing.pdf}
  \caption{High overview architecture}
  \label{fig:HighOverviewArchitecture}
\end{figure}

% \begin{figure}[h]
%   \includegraphics[width=0.5\textwidth]{diagram/drawing_png.png}
%   \caption{High overview architecture}
%   \label{fig:HighOverviewArchitecture}
% % \end{minipage}
% \end{figure}

% Figure \ref{fig:HighOverviewArchitecture} illustrates a high overview of the FAT allocator. The rectangular rectangle represents
% addresses in memory and the box from v1 to v100 represents a physically contiguous region of memory. The physically contiguous region of
% memory is normally allocated using huge pages. When malloc is called the Capability pointer is returned with meta data related to the bounds
% information encoded in the pointer. The bounds encoded in the pointer is reused for tracking memory blocks within a huge page. As shown this in
% turn reduces the TLB pressure. 

Figure \ref{fig:HighOverviewArchitecture} illustrates a high-level overview of the FAT allocator. The dotted rectangular box represents 
addresses in memory, and the box from v1 to v100 represents a physically contiguous region of memory. This physically contiguous 
region is typically allocated using huge pages. When malloc is called, a capability pointer is returned with metadata related to 
the bounds information encoded within the pointer. The bounds encoded in the pointer are reused for tracking memory blocks within a 
huge page. As shown, this in turn reduces TLB pressure.

% comparison between standard memory allocation (\textit{malloc}) and the proposed FAT method. The standard approach involves a C program interacting with a custom allocator which uses 48-bit 
% virtual addresses and the TLB hierarchy (L1, L2 and L3 cache) to achieve non-contiguous allocation in physical memory. 
% This typically results in more TLB entries and increased TLB misses increasing the reasoning to have more TLB walks. 
% In contrast, the FAT method employs a custom allocator leveraging 
% physically contiguous memory by using CHERI to encode 
% bounds within the pointers and as shown in the figure \ref{fig:HighOverviewArchitecture}. There is almost no reliance on walking the TLB hierarchy. 

% Figure \ref{fig:HighOverviewArchitecture} illustrates
% the methodology employed to use the CHERI
% 128-bit FAT-pointer scheme for facilitating
% block-based memory management on physically
% contiguous memory,which is depicted on the
% right side of the figure.
% This technique contrasts with the
% conventional approach.

% We explore how using huge pages
% with CHERI bounds can reduce the
% number of TLB entries required.

\subsection{Encoding Ranges as Bounds to the Pointer}
% \label{sec:RangeMemory}
% \begin{figure}[h]
%   \includegraphics[width=0.4\textwidth]{diagram/AllocationOverview24.png}
%   \caption{Range of memory}
%   \label{fig:RangeOfMemory}
% \end{figure}
% Integrating range bounds directly into FAT-pointers enables the CHERI architecture
% to enforce memory access restrictions at the pointer level thus allowing
% tracking of memory ranges on a pointer level. 
Range is defined from work based on RMM~\cite{karakostas_redundant_2015} and FlexPointer~\cite{chen_flexpointer_2023}. In RMM a range refers to a contiguous region of memory 
defined by a base address and a bound. This information is stored in a hardware managed table called Range Table
which is called when there is a L1 TLB miss. FlexPointer builds up on the work of RMM and stores the ID value between 48th bit 
and 64th bit which is the value to check the range table on parallel to the L1 TLB lookup. 

The FAT allocator builds up on the concept of range from RMM and FlexPointer. Instead of using a 
hardware range table using CHERI range information can be encoded within a capability pointer. 
A memory range in FAT has two points to track memory in physically contiguous space which
is the top and bottom. These two points are two virtual addresses and the range consists of
addresses that lie within this and refers to addresses allocated by invoking \textit{malloc}. 
FAT memory ranges are established using
bounds encoded within the pointer, adhering to CHERI CC~\cite{woodruff_cheri_2019} compression scheme.
% as referred in section ~\ref{sec:128bitCompressedBounds}.

% Figure \ref{fig:RangeOfMemory} illustrates a straightforward use-case in which the dark pink line represents a single
% large contiguous memory area or huge page. Within this huge page the orange and blue lines indicate
% two separate memory allocations equivalent to invoking \textit{malloc} twice to allocate memory in distinct regions.
% This scenario simulates a block-based memory allocator operating within the confines of a huge page.
% The allocations use the bounds encoded in FAT which ensures tracking of the allocated memory regions. 
% By using the CHERI bounds, this method maintains the contiguity of the allocated blocks within the huge page.

\section{128 bit compressed bounds}
\label{sec:128bitCompressedBounds}
% We use CHERI CC (Compressed bounds) to track regions of memory used in physically
% contigous space. CHERI CC consists of bounds which are compressed and represent a
% 128 bit pointer with a 64 bit virtual address system. Our appproach is to use
% a constant single cycle to encode and decode bounds. CHERI CC was originally intended
% for memory protection but can also be repurposed for tracking memory region rather
% than using the standard approach with consists of numerous TLB entries for each allocation.

% One of the key analysis highlighted by CHERI CC is that allocators such as Jemalloc always
% allocate objects under 512 bytes. When a bound of an object cannot be represented it is required
% to be padded to memory. It was noted that allocators just as Jemalloc in practice do not require
% more than 6 bits to represent exponents needed within the compressed bounds.

% This means the default behavoir of most allocators such as Jemalloc would precisely represent bounds
% within the FAT-Pointer which can be repurposed as ranges in memory allocators with custom allocation
% sizes rather than fixed sized TLB entries.

FAT uses CHERI CC~\cite{woodruff_cheri_2019} to track regions of memory in physically contiguous space.
CHERI CC consists of compressed bounds that represent a 128-bit pointer within a 64-bit virtual address
system. Our approach uses the work of CHERI CC by using a single cycle to decode bounds from the 
capability register and the bounds that are decoded are repurposed for tracking memory which is eagerly 
allocated.
% Our approach utilizes a single-cycle encoding and decoding mechanism for efficiency. While CHERI
% CC was originally designed for memory protection, it can also be repurposed for tracking memory regions,
% eliminating the need for multiple TLB entries for each allocation.

Allocators like Jemalloc typically allocate objects under
512 bytes. When an object's bounds cannot be precisely represented, padding is required to ensure
memory safety. However, it has been observed that Jemalloc rarely needs more than 6 bits to store the
exponent values within compressed bounds (as shown in~\cite{woodruff_cheri_2019}). This means that the default behavior of allocators such as Jemalloc, would allow precise
representation of bounds within CHERI CC.

% With FAT rather than using fixed size TLB entries page sizes (such as 4KB, 2MB and 1GB pages) 
% we use CHERI CC bounds to be dynamic in size to be defined based on the size provided when calling
% malloc offering a more flexible alternative than fixed-size TLB entries.

Instead of relying on fixed-size TLB entries with set page sizes (such as 4KB, 2MB, or 1GB), FAT uses CHERI 
CC to define dynamic bounds based on the size requested at allocation time (e.g., during a \textit{malloc} call). 
This approach offers flexible translation entry sizes compared to the traditional fixed-size TLB model.

This means that the default behavior of most allocators, such
as Jemalloc, would allow precise representation of bounds within
a FAT. These pointers can then be repurposed as memory ranges in custom memory allocators, offering a more flexible
alternative to fixed-size TLB entries.

% We use the CHERI CC 
% bounds to be repurposed to encode dynamic sized addresses ranges.
% These pointers can then be repurposed as memory ranges
% in custom memory allocators, offering a more flexible alternative to fixed-size TLB entries.

% \subsection{Creation of Physically Contiguous Memory Ranges}

% \smallskip\noindent
% The memory chunk defined by the upper and lower bounds is always physically contiguous.
% By defining memory regions that are physically contiguous, systems can
% achieve optimal memory access patterns, enhancing performance and efficiency.

\subsection{Instrumenting Block-Based Allocators with Physically Contiguous Memory}
% \begin{figure}[h]
%   \includegraphics[width=0.4\textwidth]{diagram/TLBAccess.drawio.png}
%   \caption{FAT Address Translations using huge pages}
%   \label{fig:HugePages}
% \end{figure}
% To build up based on Section ~\ref{sec:RangeMemory} and ~\ref{sec:128bitCompressedBounds}.
FAT is able to pre-allocate memory using huge pages and is able to mark smaller allocations
using ranges by storing them as bounds within the pointer. Each of these memory ranges can be
called a block. Since there are numerous blocks inside a huge page, This allows for abbreviated block-based
memory patterns within physically contiguous memory. 

By consolidating address translations into a single TLB entry,
this method cuts down on the overhead of managing many entries.
It also takes advantage of the bounds encoded within FAT
to track and access memory within physically contiguous memory. 

% As demonstrated with the allocator
% implementation in section ~\ref{sec:MemoryAllocator}.

%Traditional address translation methods rely on hierarchical
%structures to map virtual addresses to physical addresses.
%This often requires multiple entries to handle different
%memory segments, which increases overhead and adds complexity
%to the translation process~\cite{TLBBehavoir}. In contrast, FAT
%simplifies this by using a single TLB
%entry to translate multiple addresses within a contiguous memory
%range. This reduces the number of TLB entries needed, making the
%translation process more efficient and less complex.

%By consolidating address translations into a single TLB entry,
%the FAT cuts down on the overhead of managing many entries.
%It also takes advantage of the bounds encoded within fat-pointers
%to track and access memory. 
% This streamlined (TODO)
% approach allows for precise and effective memory management,
% especially within large, contiguous memory regions like huge pages.
%Overall, it simplifies memory operations while improving performance
%and reduces TLB overhead by reducing TLB walks.

% Figure \ref{fig:HugePages} illustrates a use-case of huge pages where the green
% line represents sample access to read within a contiguous
% space of physical memory. The dotted lines represent the
% bounds for that particular pointer access. Using bounds
% stored on the pointer a block-based pattern can be replicated
% on physically contiguous memory.

\section{Memory allocator design}
\label{sec:MemoryAllocator}
This section presents a memory allocator design which is implemented based on the
principles outlined in FAT (Section ~\ref{sec:FatPointerTranslations}). The allocator consists of three core functions: \textit{InitAlloc},
\textit{malloc}, and \textit{free}. The \textit{InitAlloc} function initialises the memory pool, setting up the necessary
data structures and metadata required for efficient memory management. The \textit{malloc} function is
responsible for allocating a contiguous block of memory of a specified size. When the \textit{free}
function deallocates memory it is returned to the pool for future use.

% A notable feature of this malloc implementation is its compatibility with kernel modules,
% where it can be integrated as an alternative to the mmap system call. This integration
% ensures that memory allocations are physically contiguous. By providing physically contiguous
% memory blocks, this allocator can serve as a foundational layer for standard block-based allocators,
% such as Jemalloc, enabling them to operate with significantly lesser L1 TLB misses with programs with heavy memory usage with smaller allocations where physical memory
% contiguity is essential.

\begin{algorithm}
  \caption{Malloc implementation}
  \label{alg:malloc}
  \begin{algorithmic}[1]
  \Function{malloc}{sz}
      \State $sz \gets \text{ALIGN\_UP}(sz, \text{MAX\_ALIGNMENT})$ \Comment{Align size to max alignment}
      \State $\text{MallocCounter} \gets \text{MallocCounter} - sz$ \Comment{Update remaining memory}
      \State $\text{ptrLink} \gets \&\text{ptr}[\text{MallocCounter}]$ \Comment{Calculate pointer address}
      \State $\text{ptrLink} \gets \text{SET\_BOUNDS}(\text{ptrLink}, sz)$ \Comment{Set bounds for memory safety and to track the length of the pointer}
      \State \Return $\text{ptrLink}$ \Comment{Return allocated memory pointer}
  \EndFunction
  \end{algorithmic}
  \end{algorithm}

When the \textit{malloc} function (Algorithm \ref{alg:malloc}) is invoked, the algorithm employs an eager allocation strategy for physical memory.
This is achieved through the use of the SetBounds mechanism. This constructs a FAT-specialised
pointer that encodes both the start and end addresses of the allocated memory region within the pointer
itself. The start and end addresses correspond to the size of the memory block requested by \textit{malloc}. This
approach introduces a method of memory tracking, where the bounds of the allocated region is
explicitly encoded in the address which enables efficient monitoring and management of memory usage.

Furthermore, this design uses huge page TLB entries to map
and track memory addresses. By encoding bounds directly into the address, the algorithm ensures that memory
accesses remain within the allocated region. Thereby reducing the risk of out-of-bounds
errors. This use of FAT and shared TLB entries not only align with the principles of
efficient memory management but also demonstrate a practical use case of huge pages in CHERI.

\begin{algorithm}
  \caption{Free implementation}
  \label{alg:free}
  \begin{algorithmic}[1]
  \Function{free}{ptr}
      \State $\text{len} \gets \text{GET\_LENGTH}(\text{ptr})$ \Comment{Get length of memory block from the defined bounds}
      \State $\text{UNMAP}(\text{ptr}, \text{len})$ \Comment{Release memory block}
  \EndFunction
  \end{algorithmic}
  \end{algorithm}

  The memory deallocation (Algorithm \ref{alg:free}) mechanism in the proposed allocator is facilitated by the FAT structure
  introduced in the \textit{malloc} algorithm. When the \textit{free} function is invoked, it uses the metadata
  embedded within FAT to determine the range and size of the allocated memory region.
  Specifically, FAT encodes the start and end addresses of each allocation and provides the information needed to 
  identify the memory block to be deallocated. This enables the allocator to accurately unmap the corresponding 
  memory region from the address space.

  % Specifically, the start and end addresses encoded in FAT to provide the necessary information
  % to identify the exact memory block to be deallocated. This allows the allocator to unmap
  % the corresponding memory region from the address space.

  By extracting the bounds and size directly from FAT, the \textit{free} function eliminates the need
  for additional metadata lookups or complex data structures.
  % , streamlining the deallocation process.
  % This approach not only enhances performance but also reduces the risk of memory leaks or fragmentation.



\begin{algorithm}
  \caption{Init alloc function to create a initial 1 GB huge page}
  \label{alg:initAlloc}
  \begin{algorithmic}[1]
  \Function{Init\_alloc}{}
      \State $\text{sz} \gets 1\ \text{GB}$ \Comment{Define pre-allocated memory size}
      \State $\text{fd} \gets \text{CREATE\_LARGE\_PAGE\_MEMORY}(\text{sz})$ \Comment{Create shared memory}
      \State $\text{ptr} \gets \text{MAP\_MEMORY}(\text{sz})$ \Comment{Map memory region}
      \State $\text{MallocCounter} \gets \text{sz}$ \Comment{Initialize memory counter}
  \EndFunction
  \end{algorithmic}
  \end{algorithm}

Algorithm \ref{alg:initAlloc} describes the initialisation of physically contiguous memory through the use of huge pages
which is a mechanism supported by modern architectures to optimise memory management. The algorithm begins by
allocating a fixed block of 1 GB physically contiguous memory. This decision is driven by the
architectural constraints of contemporary systems, particularly ARM-based CPUs. Where 1 GB represents
the largest supported page size. By leveraging huge pages, the algorithm reduces the overhead associated
with page table management and enhances memory access which is critical for performance-sensitive
applications and kernel-level operations.

\section{Embedding FAT allocator inside Jemalloc}
\label{sec:JemallocFATAllocator}
This section describes the FAT allocator implementation (Section \ref{sec:MemoryAllocator}) embedded inside Jemalloc. The objective here is to describe the changes needed
for a block based allocator to use physically contigous memory with a block based strategy with the help of capability based addresses. 
In the case of Jemalloc the only changes required was to replace the mmap with the \textit{malloc} function (Algorithm \ref{alg:malloc}) and
for munmap the \textit{free} function (Algorithm \ref{alg:free}). 

\begin{algorithm}
  \caption{Modified Jemalloc Memory Mapping Routines}
  \label{alg:JemallocMalloc}
  \begin{algorithmic}[1]
  
  \Statex \textbf{Function:} \textsc{os\_pages\_map(addr, size, alignment, commit)}
  \Require addr aligned to \texttt{os\_page}, size aligned to \texttt{os\_page}, size $\neq 0$
  \Ensure If \texttt{addr} is non-NULL (CheriABI), return NULL
  
  \If{$\text{addr} \neq \text{NULL}$}
      \State \Return NULL
  \EndIf
  
  \If{os\_overcommits}
      \State commit $\gets$ true
  \EndIf
  
  \State ret $\gets$ \textbf{MALLOC}(size)
  \State \textbf{assert}(ret $\neq$ NULL)
  
  \If{addr $\neq$ NULL \textbf{and} ret $\neq$ addr}
      \State \texttt{os\_pages\_unmap}(ret, size)
      \State ret $\gets$ NULL
  \EndIf
  
  \State \Return ret
  
  \vspace{1em}
  \Statex \textbf{Function:} \textsc{pages\_map(addr, size, alignment, commit)}
  \Require alignment $\geq$ \texttt{PAGE}, addr aligned to alignment
  
  \State ret $\gets$ \textbf{MALLOC}(size)
  
  \State \Return ret
  
  \vspace{1em}
  \Statex \textbf{Function:} \textsc{pages\_commit\_impl(addr, size, commit)}
  \Require addr aligned to \texttt{PAGE}, size aligned to \texttt{PAGE}
  
  \State result $\gets$ \textbf{MALLOC}(size)
  
  \If{result $\neq$ addr}
      \State \texttt{os\_pages\_unmap}(result, size)
      \State \Return true
  \EndIf
  
  \State \Return false
  
  \end{algorithmic}
  \end{algorithm}

\subsection{Mmap replaced with MALLOC}

The os\_pages\_map function (Algorithm~\ref{alg:JemallocMalloc}) simulates Jemalloc's low-level page
mapping routine. It first checks if a specific address is
requested in case relevant to CheriABI~\cite{CheriABI} where such behavior
is disallowed and returns NULL. It then allocates memory using the custom MALLOC(size) (Algorithm~\ref{alg:malloc}) function and validates
whether the returned pointer matches the requested address
if one was provided. If there's a mismatch, it unmaps calling FREE() (Algorithm~\ref{alg:free}) the
memory and returns NULL; otherwise, it returns the allocated
pointer.

This approach mentioned above is embedded inside Jemalloc's strategy of managing memory through arenas~\cite{jemalloc} and size~\cite{jemalloc} classes. 
In Jemalloc, memory is divided into chunks, which are further subdivided into runs and regions to 
handle allocations of various sizes efficiently. By aligning sizes and managing allocations within 
predefined structures, Jemalloc minimizes fragmentation~\cite{evans_scalable_nodate}.

% The only function required to be replaced with Malloc was os\_pages\_map, 
% pages\_map and pages\_commit\_impl as show in
% algorithm \ref{alg:JemallocMalloc}.

\begin{algorithm}
  \caption{os\_pages\_unmap}
  \label{alg:JemallocFree}
  \begin{algorithmic}[1]
  \Require addr aligned to \texttt{os\_page}, size aligned to \texttt{os\_page}
  \Ensure Memory region at \texttt{addr} is unmapped
  \State \textbf{assert}(\texttt{ALIGNMENT\_ADDR2BASE}(addr, os\_page) $=$ \texttt{addr})
  \State \textbf{assert}(\texttt{ALIGNMENT\_CEILING}(size, os\_page) $=$ size)
        
  \State \textbf{FREE}(addr)
  \end{algorithmic}
\end{algorithm}

\subsection{Munmap replaced with FREE}

The os\_pages\_unmap (Algorithm~\ref{alg:JemallocFree}) represents a customized abstraction of Jemallocs 
memory unmapping routine, designed to integrate with the previously defined simplified 
free(ptr) implementation. In conventional Jemalloc configurations, os\_pages\_unmap would 
invoke low-level system calls such as munmap to release virtual memory pages back to the 
operating system. However, in this adapted version, the function instead delegates the 
deallocation to a higher-level FREE(addr) (Algorithm~\ref{alg:free}).

The function begins by enforcing two invariants through assertions: first, that the input 
address addr is aligned to the operating system's page size and second that 
the size of the memory region is also a multiple of os\_page. These alignment checks are 
critical for maintaining consistency with Jemalloc's internal page-based memory 
management semantics and ensuring compatibility with the allocator's expectations.
Following these checks the memory at the specified address is deallocated via the 
FREE(addr) (Algorithm~\ref{alg:free}) operation.

The following changes done to free is embedded inside Jemalloc's deallocation mechanism, 
where metadata associated with each allocation 
(such as size and location) is used to efficiently return memory to the appropriate 
arena or pool. Jemalloc maintains 
separate metadata structures to track allocations, allowing for quick deallocation and 
reuse of memory blocks
without significant overhead~\cite{evans_scalable_nodate}.
    
% The only function required to be replaced with Free was 
% os\_pages\_unmap as show in
% algorithm \ref{alg:JemallocFree}. 

\section{Evaluation}
\label{sec:Evaluation}
Benchmarks of the FAT memory allocator and the FAT allocator embedded within Jemalloc against the standard Jemalloc~\cite{jemalloc} allocator was conducted.
Jemalloc is the default memory allocator for CHERIBSD~\cite{cheribsd}. The objective was to evaluate
the reduction of TLB walks and misses and its impact on the wall clock runtime.

To comprehensively analyse the implemented allocator, the benchmarks~\cite{Benchmark} were categorised into
two classes which are micro and macro benchmarks. Micro benchmarks comprise smaller
C programs designed to target specific allocator patterns such as the memory read operations which enables us to evaluate
detailed aspects of the allocators behavior. Macro benchmarks, on the other hand,
encompass larger real-world C programs allowing us to assess the allocators
performance in a more practical and real-world scenarios.

% The experiment setup (section~\ref{sec:Experiment}) details the software stack used for evaluation. It includes
% the specific configurations, compiler options, and system environment tailored
% to benchmark the proposed allocator. This ensures consistency and repeatability
% in our results, providing a solid foundation for meaningful comparisons.

% We further elaborated on the two classes of benchmarks executed. Micro benchmarks (section~\ref{sec:Micro}).
% focused on particular allocation and deallocation patterns, such as sequential and
% random memory accesses, to stress-test the allocator under controlled conditions.
% Macro benchmarks (section~\ref{sec:Macro}) involved real-world applications, offering insights into how
% the allocator performs with complex memory allocation demands, large datasets,
% and varying execution contexts.

% The results (section~\ref{sec:Results}) presents the outcomes of our benchmarks, highlighting key metrics
% such as TLB miss rates, memory usage, and runtime performance. We observed that the
% proposed allocator demonstrated significant improvements in reducing TLB misses,
% leading to noticeable enhancements in runtime efficiency for both micro and macro
% benchmarks. The behavior of specific allocation patterns and their impact on memory
% performance is detailed, providing a nuanced understanding of the allocator's effectiveness.

%Based on the evaluated results (section~\cite{sec:Usability}), the usability of the proposed allocator shows promise
%for applications requiring optimized memory management and reduced overhead from TLB misses.
%However, limitations were also identified, such as scenarios where the allocator's performance
%gains were marginal or where it introduced additional complexity in memory management. 

\subsection{Experiment setup}
\label{sec:Experiment}
The CHERI Morello~\cite{Morello} board was used to evaluate the proposed memory allocator.
Morello implements the ARMv8 with enhanced server-class memory, featuring a
quad-core ARM CPU with capability extensions. The L1 and L2 caches were modified
to proliferate the capability bit which ensures compatibility with CHERI's capability-based
memory model. When compiling the C programs for benchmarking, the Benchmark ABI~\cite{BenchmarkABI} was
used as recommended by the CHERI community. This compilation mode was enabled using
the Clang compiler.

The Benchmark ABI was specifically designed because the Morello branch predictor
was not expanded to predict bounds. Consequently, a capability-based jump introduces
stalls in later PCC-dependent(Program Counter Capability) instructions until bounds are established. This issue
is particularly significant during dynamically linked calls and returns between
libraries where bounds are changed to cover the called or returned-to library.
Such stalls can negatively affect performance, making the Benchmark ABI an essential
consideration for this evaluation.

Each C program was executed using two different memory allocators. The first was
the FAT allocator(Section ~\ref{sec:MemoryAllocator}) which is imported as a header file. This approach was necessary
because the Benchmark ABI shared object file exhibited unexpected behavior by
failing to overwrite the C program at runtime with the intended \textit{malloc} functions.
The second allocator was the standard OS memory allocator, which in the case of
CHERIBSD is Jemalloc.

Performance measurements (table ~\ref{table:ARMPerf}) were carried out using ARM hardware performance counters~\cite{PerformanceCounter} to
ensure accurate evaluation. These counters provided detailed metrics allowing
us to compare the performance of the two allocators and assess the impact of
the proposed changes.

\begin{table*}[b]
  \caption{\label{tab:org246a883}ARM performance counters}
  \centering
  \begin{tabular}{|l|l|}
  \hline
  Performance counter & Description \\
  \hline
  Wall clock & The actual time taken from the start of a \\
   & computer program to the end. \\
   & \\
  (p/l1d\_tlb\_rd) L1 data TLB reads & Level 1 data TLB access, read \\
   & \\
  (p/l2d\_tlb\_rd) L2 data TLB reads & Level 2 data TLB access, read \\
   & \\
  (p/l1d\_tlb\_refill) L1 data TLB refills & Level 1 data TLB refill. \\
   & The Level 1 data TLB refill \\
   & counter tracks each access to \\
   & the L1D\_TLB that results \\
   & in a refill of the Level 1 data \\
   & or unified TLB. This includes any \\
   & access that requires a memory lookup \\
   & due to a translation table walk \\
   & or accessing another level of TLB cache. \\
   & \\
  (p/dtlb\_walk) Data TLB walks & Data TLB access with at least \\
   & one translation table walk. \\
   & \\
  (p/ll\_cache\_miss\_rd) Last level cache miss reads & Last level cache miss, read \\
   & (This refers to every miss in the \\
   & Last level cache that occurs \\
   & during a memory read operation.) \\
  \hline
  \end{tabular}
  \label{table:ARMPerf}
  \end{table*}

\subsection{Benchmarks}
Elaborated here are two classes of benchmarks. Micro benchmarks
focus on particular allocation, deallocation patterns such as sequential and
random memory accesses. This is to stress-test the allocator under controlled conditions.
Macro benchmarks involves real-world applications offering insights into how
the allocator performs with complex memory allocation demands such as large datasets with varying execution contexts.

\subsubsection{Micro benchmark}
\label{sec:Micro}

  \begin{itemize}
  % \item \texttt{GLIBC}: The Glibc benchmark evaluates the performance of
  % \textit{malloc} and \textit{free} functions in single-threaded, multi-threaded,
  % and emulated multi-threading scenarios using various block sizes
  % allocation patterns. It simulates real-world memory usage by partially
  % deallocating blocks in FIFO order and fully deallocating them in LIFO order.
  % Results are gathered across configurations to analyse performance variations.
  
  \item \texttt{MemAccess}: This benchmark evaluates the performance impact of
  memory access patterns by constructing and traversing a doubly
  linked list with varying working set sizes. It supports sequential or
  randomised structures with optional node operations and multithreaded
  traversal using pthreads. The program dynamically allocates memory and systematically
  doubles the working set size to analyse memory hierarchy behavior.

  \item \texttt{Richards}: Richards is a task scheduling benchmark that simulates a
  multitasking environment with tasks of varying types and priorities which is
  communicated through queued packets. The schedule function manages
  task execution based on the state, priority and tracks processed packets
  which are held tasks for performance evaluation. Configurable iterations and
  timing help measure system performance to ensure correctness.
  \end{itemize}

\subsubsection{Macro benchmark}
\label{sec:Macro}

\begin{itemize}
\item \texttt{Kmeans}: Kmeans implements a parallelised K-means clustering algorithm that
assigns data points to clusters based on proximity to the centroids.
This iteratively updates them until convergence. The computation is
distributed across threads using the pthread library, dynamically
assigning tasks to optimise performance. Parameters like data size
and clusters are configurable and the program ensures efficient
memory management and synchronisation.

\item \texttt{XSBench}: XSBench~\cite{XSBench} is a simplified version of the OpenMC Monte Carlo code 
that focuses only on the most time-consuming part: calculating macroscopic neutron cross sections. 
Instead of running a full particle transport simulation it uses a benchmark reactor model,
a large unionised energy grid to reproduce the same types of calculations and memory use patterns 
but with far less complexity. The key point is that cross-section lookups involve many random accesses 
to large data tables in memory, rather than a small amount of repeated arithmetic. This makes performance 
heavily dependent on how quickly data can be read from and written to different levels of the memory 
hierarchy (caches, main memory). XSBench is therefore closely tied to studying memory reads and writes, 
since it allows researchers to see how modern processors handle the irregular, data-intensive behaviour 
that dominates in real Monte Carlo simulations.

\item \texttt{BARNES}: Implements the Barnes-Hut algorithm to efficiently simulate the interactions within 
an \(N\)-body system. A comprehensive overview of the Barnes-Hut method is provided by Singh in his doctoral 
dissertation ~\cite{singh1993}. This implementation extends the original method by permitting multiple 
particles to be stored within each leaf cell of the spatial decomposition, enhancing performance and scalability. 
This extension is described by Holt and Singh ~\cite{holt1995}.
\end{itemize}


\subsection{Results and discussion}
\label{sec:Results}

% \begin{figure}[b]
%   \centering
%   \begin{subfigure}{.5\textwidth}
%       \centering
%       \includegraphics[width=0.45\textwidth]{diagram/benchmarks-group/bargraph-large-dtlb-walk.png}
%   \end{subfigure}%
%   \begin{subfigure}{.5\textwidth}
%       \centering
%       \includegraphics[width=0.45\textwidth]{diagram/benchmarks-group/bargraph-large-dtlb-walk.png}
%   \end{subfigure}
%   \begin{subfigure}{.5\textwidth}
%       \centering
%       \includegraphics[width=0.45\textwidth]{diagram/benchmarks-group/bargraph-large-dtlb-walk.png}
%   \end{subfigure}%
%   \begin{subfigure}{.5\textwidth}
%       \centering
%       \includegraphics[width=0.45\textwidth]{diagram/benchmarks-group/bargraph-large-dtlb-walk.png}
%   \end{subfigure}
%   \begin{subfigure}{\textwidth}
%       \raggedleft
%       \includegraphics[width=0.45\textwidth]{IMAGE NAME}
%   \end{subfigure}
%   \caption[short]{A beautiful, well written caption}
%   \end{figure}

% \begin{figure*}
%   \begin{multicols}{2}
%       \includegraphics[width=\linewidth]{diagram/benchmarks-group/bargraph-large-dtlb-walk.png}\par 
%       \includegraphics[width=\linewidth]{diagram/benchmarks-group/bargraph-large-l1tlb-reads.png}\par 
%       \end{multicols}
%   \begin{multicols}{2}
%       \includegraphics[width=\linewidth]{diagram/benchmarks-group/bargraph-large-l1tlb-refill.png}\par
%       \includegraphics[width=\linewidth]{diagram/benchmarks-group/bargraph-large-l2tlb-reads.png}\par
%   \end{multicols}
%   \begin{multicols}{2}
%     \includegraphics[width=\linewidth]{diagram/benchmarks-group/bargraph-large-ll-cache-rd.png}\par
%     \includegraphics[width=\linewidth]{diagram/benchmarks-group/bargraph-large-wallclock.png}\par
% \end{multicols}
%   \caption{Benchmarks comparing the percentage difference between FAT }
%   \end{figure*}

\begin{figure*}
  \begin{multicols}{2}
    \begin{subfigure}{\linewidth}
      \includegraphics[width=\linewidth]{diagram/Benchmarks/l1_tlb_rd.png}
      \caption{L1 TLB Reads}
      \label{fig:l1tlb-reads}
    \end{subfigure}\par 
    \begin{subfigure}{\linewidth}
      \includegraphics[width=\linewidth]{diagram/Benchmarks/l2_tlb_rd.png}
      \caption{L2 TLB Reads}
      \label{fig:l2tlb-reads}
    \end{subfigure}\par 
  \end{multicols}

  \begin{multicols}{2}
    \begin{subfigure}{\linewidth}
      \includegraphics[width=\linewidth]{diagram/Benchmarks/dtlb_walk.png}
      \caption{DTLB Walks}
      \label{fig:dtlb-walk}
    \end{subfigure}\par 
    \begin{subfigure}{\linewidth}
      \includegraphics[width=\linewidth]{diagram/Benchmarks/l1_tlb_refill.png}
      \caption{L1 DTLB Refill}
      \label{fig:l1tlb-refill}
    \end{subfigure}\par 
  \end{multicols}

  \begin{multicols}{2}
    \begin{subfigure}{\linewidth}
      \includegraphics[width=\linewidth]{diagram/Benchmarks/ll_cache_miss_rd.png}
      \caption{LL Cache Reads}
      \label{fig:ll-cache-rd}
    \end{subfigure}\par 
    \begin{subfigure}{\linewidth}
      \includegraphics[width=\linewidth]{diagram/Benchmarks/wall_clock.png}
      \caption{Wall Clock Time}
      \label{fig:wallclock}
    \end{subfigure}\par 
  \end{multicols}

  \caption{Benchmarks comparing the percentage difference between FAT.}
  \label{fig:benchmarks-group}
\end{figure*}

% \begin{figure*}[h]
% \includegraphics[width=.9\linewidth]{diagram/benchmarks-group/bargraph-large-dtlb-walk.png}
% \caption{\label{fig:bargraph}Percentage difference between the modified memory allocator against the default system memory allocator}
% \end{figure*}
% \begin{figure*}[h]
%   \includegraphics[width=.9\linewidth]{diagram/benchmarks-group/bargraph-large-dtlb-walk.png}
%   \caption{\label{fig:bargrapwh}Percentage difference between the modified memory allocator against the default system memory allocator}
%   \end{figure*}

Figure~\ref{fig:benchmarks-group} highlights the performance comparison between the modified memory allocator and
Jemalloc, the default memory allocator. The FAT memory allocator is specifically optimised
for use with huge pages and demonstrates a clear advantage in scenarios where memory allocation
patterns benefit from its design. The results align with expectations, showcasing the impact
of its capability to handle memory more efficiently by leveraging huge pages.

\begin{itemize}
  % \item L1 DTLB reads: L1 Data TLB reads are critical for achieving fast memory access, and a reduction 
  % in events that could signify misses or lead to further lookups is generally beneficial. FAT allocator consistently performed 
  % at the baseline level (100\%) across all benchmarks including Kmeans, Memaccess, Glibc, Richards, and Barnes. 
  % In contrast, FAT allocator embedded inside Jemalloc exhibited varied performance. It achieved a notable 14\% 
  % reduction in L1D TLB reads for Kmeans and a minor 3\% reduction for Barnes. More significantly, it 
  % led to a substantial 68\% reduction for Memaccess, a benchmark characterized by linked list traversals 
  % that can challenge memory access efficiency, and a 59\% reduction for Glibc, which involves numerous memory 
  % allocation and deallocation operations. For the Richards benchmark, however, no significant change was observed with 
  % FAT allocator embedded inside Jemalloc. These results suggest that FAT allocator embedded inside Jemalloc may arrange memory 
  % in a manner that enhances spatial locality at the page level, particularly for workloads like Memaccess and Glibc.

  \item L1 DTLB reads (Figure~\ref{fig:l1tlb-reads}): L1 TLB reads are critical for achieving fast memory access; therefore, a 
  reduction in events that could signify misses or lead to further lookups is generally beneficial.
   In the Kmeans benchmark, the FAT allocator demonstrated 13\% fewer L1 TLB reads than the baseline allocator. 
   However, when the FAT allocator was embedded within Jemalloc the L1 TLB reads were the same as the baseline. 
   For memaccess, XSBench and Richards benchmark the L1 TLB were the same as the baseline for both allocators. 
   For the Barnes benchmark, the FAT allocator exhibited 5\% 
   fewer L1 TLB reads, and the result was the same for the FAT allocator embedded within Jemalloc.

  %  For the memaccess benchmark, the embedded FAT allocator resulted in 68\% fewer L1 TLB reads compared to the baseline 
  %  allocator. A similar pattern was observed with Glibc, showing 59\% fewer L1 TLB reads. In the Richards benchmark, 
  %  there was no difference for either allocator. For the Barnes benchmark, the FAT allocator exhibited 5\% 
  %  fewer L1 TLB reads, and the result was the same for the FAT allocator embedded within Jemalloc.
  
  % \item L2 DTLB reads (Figure~\ref{fig:l2tlb-reads}): L2 Data TLB reads serve as a secondary cache for address translations. 
  % FAT allocator consistently performed at 98\% lesser L2 TLB reads for this metric across all benchmarks except Barnes
  % which was 4\% lesser. FAT allocator embedded inside Jemalloc also showed significant change of more than 86\% reduction of L2 TLB reads for Kmeans, XSBench, Memaccess and Richards.
  % This means that most reads are hit at the L1 TLB.
  % A minor reduction of 5 \% was also observed for the Barnes benchmark with FAT allocator embedded inside Jemalloc.
  % This mirrors its L1D TLB improvement for Glibc and suggests that its 
  % strategy for page locality extends effectively to deeper levels of the TLB hierarchy for this particular benchmark, which is notable given 
  % Glibc's high frequency of malloc calls that stress memory management. 

  \item L2 DTLB reads (Figure~\ref{fig:l2tlb-reads}): L2 Data TLB reads act as a secondary cache for address translations. 
  The FAT allocator consistently reduced L2 TLB reads by around 98\% across all benchmarks, with the exception of Barnes, 
  where the reduction was 4\%. When embedded within Jemalloc, the FAT allocator also achieved substantial improvements, lowering L2 TLB reads by more than 86\% for Kmeans, XSBench, Memaccess, and Richards. 
  These results indicate that the majority of address translation requests are successfully resolved at the L1 TLB 
  level, thereby avoiding the need to access deeper levels of the memory hierarchy.


  \item DTLB walks (Figure~\ref{fig:dtlb-walk}): which occur when a virtual-to-physical 
  address translation is not found in the DTLB and a page table traversal is necessary, represent a performance 
  cost. thus, fewer walks are preferable. In the observed tests neither FAT allocator nor FAT allocator embedded inside Jemalloc 
  demonstrated significant deviation from the baseline performance of 99\% lesser walks. 
  This consistent behavior was noted across all benchmarks evaluated: Kmeans, Memaccess, XSBench, Richards, and Barnes. 
  This indicates that almost all address translations were resolved directly at the L1 DTLB level 
  without triggering expensive traversals through the page table. More generally, this finding 
  demonstrates that both allocator designs make efficient use of the hardware translation system and 
  maintain consistently low page walk overheads across a range of workloads.

  % This outcome suggests that most translations were done at the L1 DTLB level.

  % the memory allocation strategies employed by these allocators do substantially alter the frequency 
  % of DTLB misses that necessitate page table walks within these specific workloads. Even for the Memaccess benchmark, 
  % which is designed with random list traversals that can stress TLB pressure, the impact on dTLB walks was negligible according to the provided graphs.

  \item L1 DTLB refills (Figure~\ref{fig:l1tlb-refill}): L1 Data DTLB refills are a direct consequence of L1 DTLB misses; therefore, fewer refills 
  indicate better performance. Interestingly, despite the variations observed in L1 DTLB reads for the FAT allocator 
  embedded within Jemalloc, the L1 DTLB refills metric showed a significant reduction of 99\% for both the standalone 
  FAT allocator and the FAT allocator embedded within Jemalloc. This consistent and substantial improvement over the baseline was observed across all tested benchmarks: Kmeans, Memaccess, XSBench, Richards, and Barnes.
  
  % L1 Data TLB refills are a direct consequence of L1D TLB misses, with fewer refills indicating better performance. 
  % Interestingly, despite the variations observed in L1D TLB reads for FAT allocator embedded inside Jemalloc, the L1D TLB refills metric 
  % resulted at a significant reduction of 99\% lesser for both FAT allocator and FAT allocator embedded inside Jemalloc. This consistent performance at baseline 
  % was observed across all tested benchmarks: Kmeans, Memaccess, Glibc, Richards, and Barnes.
  % The absence of change in refills might suggest that the "reads" metric captures a wider range of TLB interaction 
  % events than solely those leading to refills, or perhaps the absolute number of critical misses resulting in refills was minimal to begin with and thus 
  % not significantly affected by the allocators in these tests.

  % \item Last-level cache (Figure~\ref{fig:ll-cache-rd}): Cache read misses in the Last-Level Cache (LLC) are critical performance indicators, as they typically lead to 
  % slower data retrievals from main memory. Consequently, a lower number of misses is highly desirable. The performance on this 
  % metric varied considerably across both allocators and benchmarks. The FAT allocator exhibited the highest variance in the 
  % kmeans benchmark, achieving 57\% fewer cache misses compared to the baseline allocator. In contrast, it recorded 18\% more 
  % misses in memaccess, 65\% fewer in glibc, 31\% more in Richards, and 18\% more in barnes.
  % When the FAT allocator was embedded within Jemalloc, the results shifted notably: kmeans experienced 19\% more misses 
  % relative to the baseline, memaccess saw a substantial 77\% reduction, while glibc incurred a dramatic 370\% increase particularly 
  % significant given its malloc intensive nature. There was no change in LLC misses for Richards, whereas barnes suffered from 68\% 
  % more misses.

  \item Last-level cache (Figure~\ref{fig:ll-cache-rd}): Cache read misses in the Last-Level Cache (LLC) are important performance 
  indicators, as each miss typically results in slower data retrieval from main memory. Thus, fewer misses are 
  generally preferable. The results for this metric show notable variation across both allocators and benchmarks. 
  With the FAT allocator, kmeans achieved a 57\% reduction in LLC misses, while memaccess showed no meaningful 
  change. In contrast, XSBench experienced 6\% more misses, Richards 32\% more, and Barnes 19\% more compared to 
  the baseline. When the FAT allocator was embedded within Jemalloc, the behaviour shifted: kmeans recorded 19\% more misses, 
  memaccess again showed negligible change, XSBench improved slightly with 3\% fewer misses, Richards had a marginal 1\% 
  increase, and Barnes exhibited a substantial 69\% increase.
  
  
  % Last-Level Cache read misses are crucial performance indicators, as they often result in slow data fetches 
  % from main memory therefore fewer misses are highly desirable. The performance on this metric varied significantly between the 
  % allocators and across benchmarks. FAT allocator had a highest variance for kmeans with 57\% lesser cache misses than than the
  % baseline allocator, memaccess with 18\% more, Glibc with 65\% less, Richards with 31\% more and barnes with 18\% more as well. 
  % In the case of FAT allocator embedded inside jemalloc kmeans stands with 19\% more misses than the baseline allocator, memaccess with 77\%
  % lesser misses, Glibc with 370\% more misses which is significant especially being malloc heavy benchmark, Richards has no difference in
  % LL cache misses and barnes has a 68\% more cache misses. 
  % FAT allocator was near baseline for Kmeans but caused an 18\% increase in misses for Memaccess (designed to stress cache ), 
  % a 30\% increase for Richards (many dynamic allocations and pointer manipulations ), and an 18\% increase for Barnes (uses pointer-based octrees ). However, 
  % FAT allocator achieved a significant 60\% reduction in misses for the Glibc benchmark, which involves active memory use post-allocation.
  % FAT allocator embedded inside Jemalloc showed a 75\% reduction in misses for Memaccess, a substantial improvement. Conversely, it led to an 18\% increase in 
  % misses for Kmeans, a massive 375\% increase for Glibc, and a 65\% increase for Barnes. For the Richards benchmark, its performance was at the baseline. 
  % This high variability indicates that memory placement strategies of the allocators interact diversely with the specific access patterns of each benchmark, 
  % such as the difference between the large data arrays in K-Means  versus the linked structures common in Memaccess  or Richards.

  \item Wall clock (Figure~\ref{fig:wallclock}): Wallclock time serves as the definitive metric for evaluating overall execution performance. 
  When using the FAT allocator, XSBench demonstrated the most significant improvement, with a 11\% reduction in wallclock 
  runtime compared to the baseline allocator. This was followed by memaccess, barnes with a 4\% decrease
  and kmeans with a modest 1.8\% improvement. 
  Richards exhibited a slight increase of 1\% in runtime.
  When the FAT allocator was integrated into Jemalloc, the performance impact varied. Memaccess and XSBench demonstrated similar
  improvements compared to the FAT allocator. 
  in wallclock time, while barnes showed a 7\% rise. Both Richards and kmeans maintained the same runtime as the baseline 
  allocator.
  In regards to memaccess (Figure~\ref{fig:Memaccess}) the comparative performance of two allocators FAT allocator embedded inside jemalloc 
  (depicted by the solid blue line with circular markers) and FAT allocator (represented by the dashed orange line with square markers)
  across progressively increasing memory access iterations ranging from 500 to 64,000. The results indicate that the standalone FAT allocator 
  exhibits superior performance at smaller memory sizes, maintaining an initial lead of approximately 0.78\% at size 500. However, 
  its trajectory is characterised by minor fluctuations as memory size increases. Conversely, the jemalloc embedded allocator demonstrates 
  a more consistent and steadily rising performance pattern. The annotated red values denote the performance differential between the two 
  allocators. Although the FAT allocator retains an advantage in the lower ranges, this advantage progressively diminishes with increasing memory reads. 
  Notably, at the largest tested size of 64,000, the difference marginally reverses (–0.07), with the jemalloc-embedded allocator slightly outperforming. 
  Overall, the findings suggest that while the FAT allocator is more effective at smaller scales, the jemalloc embedded FAT allocator exhibits superior scalability 
  and reliability across larger memory reads.
  
  % Wallclock time provides the ultimate measure of overall execution performance, In terms of the FAT allocator GLibc 
  % had a biggest difference of 51\% lesser wall clock run time than the baseline allocator, following this memaccess with a 34\% reduction
  % , 3rd being Barnes being 4\% lesser, 4th being Kmeans with 1.8\% less and Richards having 1\% more. In terms of Jemalloc embedded inside 
  % the FAT allocator Glibc having a increased wall clock run time of 16.2\%, followed by Barnes with a 7\% increase, Richards and Kmeans
  % with the same wall clock run time as the baseline allocator. Memaccess showed a decrease in the wall clock runtime by 4\%.
  % where lower values (deviations below 100\%) indicate improvement. 
  % FAT allocator resulted in a 1\% speedup for Kmeans and a more significant 5\% speedup for Barnes. This improvement for Barnes was observed despite an increase 
  % in its LL cache misses, suggesting other factors such as reduced allocator overhead or better CPU pipeline utilization might have contributed. 
  % For Memaccess and Glibc, FAT allocator performed at the baseline. Notably, the substantial LL cache miss reduction seen with FAT allocator on Glibc did not 
  % translate into an overall speedup. It was about 1\% slower on Richards.
  % FAT allocator embedded inside Jemalloc was 4\% faster for Memaccess, aligning well with its significant LL cache miss reduction and L1D TLB improvements 
  % for that benchmark. It performed at baseline for Kmeans and was negligibly faster (0.5\%) for Richards. However, it was 15\% slower for Glibc, a slowdown 
  % consistent with the massive increase in LL cache misses observed. For Barnes, it resulted in an 8\% slowdown, which also correlates with its increased 
  % LL cache misses for that benchmark. These wallclock results underscore that improvements in a single specific memory subsystem metric do not always guarantee 
  % an overall application speedup, as the interplay of various factors determines the final performance.
  \end{itemize}

  \begin{figure}[htbp]
    \includegraphics[width=\linewidth]{diagram/benchmarks-group/Memaccess_size.png}
    \caption{Memaccess percentage increase in wallclock run times}
    \label{fig:Memaccess}
  \end{figure}

Overall, the evaluation shows that the FAT allocator provides consistent improvements in 
TLB efficiency, with near elimination of L1 refills and L2 reads across all benchmarks, 
thereby reducing pressure on the memory translation subsystem. Its effect on last-level 
cache behaviour is more variable, with notable gains in Kmeans but regressions in other 
workloads such as Richards and Barnes. Wall-clock performance reflects these mixed results: 
while XSBench and Memaccess benefit from measurable reductions in execution time, benchmarks 
with irregular access patterns (e.g., Richards) show little to no improvement. A closer comparison 
of Memaccess further reveals that the standalone FAT allocator performs best at smaller memory scales, 
whereas the Jemalloc-embedded FAT allocator demonstrates superior scalability and stability as memory 
sizes increase. These findings suggest that FAT's huge-page-oriented design is particularly effective 
for workloads with predictable or structured access patterns, whilst integration with Jemalloc enhances 
adaptability for larger or more irregular memory usage.

% A particularly striking observation is the significant reduction in data TLB walks,
% L2 data TLB reads and TLB refills-consistently which show a 90\% decrease across all
% benchmarks compared to Jemalloc. This improvement is due to the modified allocators
% use of a single huge page entry at the L1 TLB layer. By enabling most address translations
% to be resolved directly at the L1 TLB, the need to walk through the deeper TLB hierarchy is
% largely eliminated. This reduction in translation overhead is a key factor in the allocators
% performance for certain types of workloads.

% The micro benchmarks which are crafted to emphasise memory read operations, highlight the
% allocators strengths. These tests simulate frequent and intensive memory access patterns,
% where the reduction in TLB misses directly translate into measurable performance gains.
% On average, the FAT allocator achieves a 50\% reduction in wall clock runtimes for
% these workloads underscoring its ability to optimise high-throughput memory operations.

% On the other hand, macro benchmarks which represent larger and more complex real-world applications, 
% exhibit minimal differences in wall clock runtimes when using the FAT allocator.
% This outcome is expected, as macro benchmarks typically involve a broader range of operations
% beyond memory allocation. Additionally,
% the benefits of huge pages may be less pronounced for these workloads, as they are often
% bottlenecked by factors such as computation or I/O rather than memory translation overhead.

% \begin{figure}[htbp]
%   \centering
%   \includegraphics[width=1.1\linewidth]{./diagram/kmeans.png}
%   \caption{\label{fig:org8683315}Kmeans COZ benchmark executed against various cluster sizes}
% \end{figure}

% The K-means algorithm was executed with varying cluster sizes as shown in figure~\ref{fig:org8683315}, to evaluate the performance difference
% between the FAT allocator and Jemalloc as the workload scales. This analysis
% aims to understand how the allocators optimisations, particularly its ability to manage memory
% more efficiently with huge pages, impact performance under different workload conditions.

% For most cluster sizes tested, the percentage difference in performance remained relatively
% consistent. This indicates that the allocators efficiency scales predictably with increasing
% workload sizes. Suggesting a stable and uniform benefit across different configurations. The
% consistent performance gain is likely due to the allocators ability to minimise TLB misses
% and efficiently manage memory allocations for the centroid and data point structures used in
% the K-means algorithm.

% However, an anomaly was observed at a cluster size of 200k, where the percentage difference
% deviated significantly from the trend. At this cluster size, the memory access patterns and allocation behavior may align in a way that
% temporarily offsets the advantages of the FAT allocator. For example, the memory layout
% might interact with system-level caching mechanisms or TLB behavior differently leading to an
% unexpected change in performance. Additionally, the increased complexity of managing a higher
% number of clusters might introduce computational overhead that overshadows the memory allocators
% optimisations.

% This observation highlights the importance of testing across a range of workload sizes and
% configurations to uncover edge cases or specific scenarios where performance deviates from the
% expected pattern. Understanding these anomalies can provide insights into the allocator's
% behavior and guide future improvements to address such outliers. Despite the deviation at a
% cluster size of 2000, the overall results reaffirm the allocator's capability to maintain
% consistent performance benefits across most scenarios.

% \subsection{Analysis}
% \label{sec:Analysis}

% The FAT memory allocator and the modified Jemalloc demonstrates significant potential for enhancing
% memory management in systems that benefit from huge page optimisations. Its design
% effectively reduces TLB misses, achieving up to 90\% fewer data TLB walks, L2 TLB reads,
% and TLB refills compared to the system allocator (i.e default Jemalloc). These improvements lead to noticeable performance
% gains especially in micro benchmarks, where the allocator reduces wall clock runtimes
% by an average of 50\%.

% The allocator integrates seamlessly into memory read intensive workloads, as evidenced by its
% consistent performance across varying cluster sizes in the K-means benchmark with only
% minor anomalies observed under specific conditions. These outliers provide valuable
% insights into the allocators interaction with system-level caching and memory translation mechanisms.

% While the allocator excels in scenarios emphasising on high-memory throughput. Its impact on
% macro benchmarks is less pronounced. This suggests that its benefits are most relevant for
% applications with frequent and intensive memory operations rather than are compute-bound workloads.

% \section{Future work}
% The current experimental setup on the ARM Morello board is constrained by the requirement that all memory reads must
% pass through the  (TLB) for address translation. This necessitates frequent TLB lookups, potentially
% leading to performance bottlenecks. The planned future work aims to address this by leveraging CHERI
% (Capability Hardware Enhanced RISC Instructions) extensions on the RISC-V architecture, specifically using the
% Tooba implementation.

% \subsection{Storing Offsets Directly on Pointers}
% 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. 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:

% CHERI capabilities allow pointers to carry metadata about memory bounds, providing hardware-enforced memory safety.
% By encoding the offset and bounds within the pointer, the system can directly access memory without needing intermediate translations via the TLB.
% This enables the implementation of a block-based allocator that can efficiently manage memory allocations and deallocations within defined bounds.
% Bypassing the TLB in RISC-V Tooba.

% \subsection{Hardware Modifications:}
% The Bluespec design of the RISC-V processor will be modified to allow certain memory operations to bypass the TLB. This means that when a pointer with encoded offset and bounds is used, the system can directly compute the physical address from the capability information.
% This modification reduces the dependency on the TLB, decreasing latency and improving performance, especially for frequent memory operations.

% \section{Conclusion}  %Title of the Conclusion
% This paper has presented FAT, a memory allocator 
% designed to address the growing mismatch between application memory demands and 
% the limited reach of TLBs in modern processors. 
% By leveraging physically contiguous memory through huge pages and embedding 
% allocation metadata within CHERI's compressed capability based pointers, 
% FAT significantly reduces the overhead associated with virtual-to-physical 
% address translation.
% \newline
% FAT achieves block-based allocation within huge pages, enabling memory tracking 
% without relying heavily on traditional page table mechanisms. Benchmark evaluations
% demonstrate that FAT can reduce TLB walks by up to 99\%, resulting in substantial 
% performance improvements in memory-intensive workloads. When applied to 
% microbenchmarks, FAT reduced wall-clock runtime by up to 11\% for XSBench and 
% 4\% for Memaccess, while also achieving up to 98\% 
% fewer L2 TLB reads. In contrast, macro benchmarks such as Kmeans and Barnes 
% showed more modest gains of 1.8\% and 4\% in runtime, respectively, reflecting 
% the allocator's limited impact in compute-bound scenarios.
% \newline
% Although performance gains are less significant for larger or computation-heavy applications, 
% the results underscore the allocator's potential to enhance memory management in 
% high-throughput environments. More broadly, this work demonstrates how 
% capability based architectures originally designed to ensure memory safety can 
% be effectively repurposed to optimise address translation. 
% FAT thus represents a promising direction for developing more scalable 
% and efficient memory allocation strategies in systems adopting 
% capability aware architectures.

\section{Conclusion} %Title of the Conclusion
This paper has presented FAT, a memory allocator designed to 
address the growing mismatch between application memory demands and the 
limited reach of TLBs in modern processors. By leveraging physically contiguous 
memory through huge pages and embedding allocation metadata within CHERI's 
compressed capability-based pointers, FAT significantly reduces the overhead 
associated with virtual-to-physical address translation.

FAT achieves block-based allocation within huge pages, enabling memory 
tracking without relying heavily on traditional page table mechanisms. 
Benchmark evaluations demonstrate that FAT can reduce TLB walks by up to 99\%, 
resulting in substantial improvements in memory-intensive workloads. 
When applied to micro-benchmarks, FAT reduced wall-clock runtime by up to 4\% 
for Memaccess and maintained near-baseline performance for Richards, while 
also achieving up to 98\% fewer L2 TLB reads. In contrast, macro-benchmarks 
such as XSBench, Kmeans, and Barnes showed runtime improvements of 11\%, 1.8\%, and 4\%, 
respectively, reflecting the allocator’s stronger benefits in memory-bound scenarios 
compared to compute-heavy ones.

Overall, the evaluation shows that FAT provides consistent improvements in TLB efficiency, 
with near elimination of L1 refills and L2 reads across all benchmarks, thereby reducing 
pressure on the memory translation subsystem. Its effect on last-level cache behaviour 
is more variable, with notable gains in Kmeans but regressions in workloads such as 
Richards and Barnes. Wall-clock performance reflects these mixed outcomes: while XSBench 
and Memaccess benefit from measurable reductions in execution time, workloads with irregular 
access patterns (e.g., Richards) show little to no improvement. A closer comparison of Memaccess 
further reveals that the standalone FAT allocator performs best at smaller memory scales, whereas 
the Jemalloc-embedded FAT allocator demonstrates superior scalability and stability as memory sizes increase.

Although performance gains are less significant for larger or computation-heavy applications, the results 
underscore the allocator's potential to enhance memory management in high-throughput environments. More broadly, 
this work demonstrates how capability-based architectures, originally designed to ensure memory safety, can be effectively 
repurposed to optimise address translation. FAT thus represents a promising direction for developing more scalable and efficient 
memory allocation strategies in systems adopting capability-aware architectures.

% This paper addresses the growing disparity between application workloads and the capacity of TLBs.
% To mitigate this gap, FAT proposed leveraging physically contiguous memory with CHERI bounds to reduce TLB walks. 
% FAT is a memory allocator that uses huge pages with the CHERI CC scheme to track allocations within the 
% allocated huge page. 


% This approach reduces the number of TLB entries needed while using bounds
% to minimise fragmentation.
% Additionally,
% the report explores advancements in system security, particularly through the Capability Hardware Enhanced RISC Instructions (CHERI)
% architecture. CHERI's capability-based addressing enhances system security by associating capabilities with memory pointers,
% restricting access to memory regions, and thus protecting against various security threats. Importantly, these mechanisms
% can also improve the reduction of TLB walks to memory allocators by using CHERI bounds while maintaining CHERI's security guarantees.

% \newline
% The benchmarks demonstrates the FAT allocator and the FAT allocator embedded within Jemalloc which reduces the TLB walks by upto 99\%,
% leading to substantial performance gains in memory-intensive workloads, though the improvements are less pronounced
% for larger and computation-heavy applications. These results highlight the allocators potential to advance memory management
% by repurposing CHERI's capability-based model with the use of huge pages.





% \section{Template Overview}
% As noted in the introduction, the ``\verb|acmart|'' document class can
% be used to prepare many different kinds of documentation --- a
% double-anonymous initial submission of a full-length technical paper, a
% two-page SIGGRAPH Emerging Technologies abstract, a ``camera-ready''
% journal article, a SIGCHI Extended Abstract, and more --- all by
% selecting the appropriate {\itshape template style} and {\itshape
%   template parameters}.

% This document will explain the major features of the document
% class. For further information, the {\itshape \LaTeX\ User's Guide} is
% available from
% \url{https://www.acm.org/publications/proceedings-template}.

% \subsection{Template Styles}

% The primary parameter given to the ``\verb|acmart|'' document class is
% the {\itshape template style} which corresponds to the kind of publication
% or SIG publishing the work. This parameter is enclosed in square
% brackets and is a part of the {\verb|documentclass|} command:
% \begin{verbatim}
%   \documentclass[STYLE]{acmart}
% \end{verbatim}

% Journals use one of three template styles. All but three ACM journals
% use the {\verb|acmsmall|} template style:
% \begin{itemize}
% \item {\texttt{acmsmall}}: The default journal template style.
% \item {\texttt{acmlarge}}: Used by JOCCH and TAP.
% \item {\texttt{acmtog}}: Used by TOG.
% \end{itemize}

% The majority of conference proceedings documentation will use the {\verb|acmconf|} template style.
% \begin{itemize}
% \item {\texttt{sigconf}}: The default proceedings template style.
% \item{\texttt{sigchi}}: Used for SIGCHI conference articles.
% \item{\texttt{sigplan}}: Used for SIGPLAN conference articles.
% \end{itemize}

% \subsection{Template Parameters}

% In addition to specifying the {\itshape template style} to be used in
% formatting your work, there are a number of {\itshape template parameters}
% which modify some part of the applied template style. A complete list
% of these parameters can be found in the {\itshape \LaTeX\ User's Guide.}

% Frequently-used parameters, or combinations of parameters, include:
% \begin{itemize}
% \item {\texttt{anonymous,review}}: Suitable for a ``double-anonymous''
%   conference submission. Anonymizes the work and includes line
%   numbers. Use with the \texttt{\acmSubmissionID} command to print the
%   submission's unique ID on each page of the work.
% \item{\texttt{authorversion}}: Produces a version of the work suitable
%   for posting by the author.
% \item{\texttt{screen}}: Produces colored hyperlinks.
% \end{itemize}

% This document uses the following string as the first command in the
% source file:
% \begin{verbatim}
% \documentclass[sigconf,authordraft]{acmart}
% \end{verbatim}

% \section{Modifications}

% Modifying the template --- including but not limited to: adjusting
% margins, typeface sizes, line spacing, paragraph and list definitions,
% and the use of the \verb|\vspace| command to manually adjust the
% vertical spacing between elements of your work --- is not allowed.

% {\bfseries Your document will be returned to you for revision if
%   modifications are discovered.}

% \section{Typefaces}

% The ``\verb|acmart|'' document class requires the use of the
% ``Libertine'' typeface family. Your \TeX\ installation should include
% this set of packages. Please do not substitute other typefaces. The
% ``\verb|lmodern|'' and ``\verb|ltimes|'' packages should not be used,
% as they will override the built-in typeface families.

% \section{Title Information}

% The title of your work should use capital letters appropriately -
% \url{https://capitalizemytitle.com/} has useful rules for
% capitalization. Use the {\verb|title|} command to define the title of
% your work. If your work has a subtitle, define it with the
% {\verb|subtitle|} command.  Do not insert line breaks in your title.

% If your title is lengthy, you must define a short version to be used
% in the page headers, to prevent overlapping text. The \verb|title|
% command has a ``short title'' parameter:
% \begin{verbatim}
%   \title[short title]{full title}
% \end{verbatim}

% \section{Authors and Affiliations}

% Each author must be defined separately for accurate metadata
% identification.  As an exception, multiple authors may share one
% affiliation. Authors' names should not be abbreviated; use full first
% names wherever possible. Include authors' e-mail addresses whenever
% possible.

% Grouping authors' names or e-mail addresses, or providing an ``e-mail
% alias,'' as shown below, is not acceptable:
% \begin{verbatim}
%   \author{Brooke Aster, David Mehldau}
%   \email{dave,judy,steve@university.edu}
%   \email{firstname.lastname@phillips.org}
% \end{verbatim}

% The \verb|authornote| and \verb|authornotemark| commands allow a note
% to apply to multiple authors --- for example, if the first two authors
% of an article contributed equally to the work.

% If your author list is lengthy, you must define a shortened version of
% the list of authors to be used in the page headers, to prevent
% overlapping text. The following command should be placed just after
% the last \verb|\author{}| definition:
% \begin{verbatim}
%   \renewcommand{\shortauthors}{McCartney, et al.}
% \end{verbatim}
% Omitting this command will force the use of a concatenated list of all
% of the authors' names, which may result in overlapping text in the
% page headers.

% The article template's documentation, available at
% \url{https://www.acm.org/publications/proceedings-template}, has a
% complete explanation of these commands and tips for their effective
% use.

% Note that authors' addresses are mandatory for journal articles.

% \section{Rights Information}

% Authors of any work published by ACM will need to complete a rights
% form. Depending on the kind of work, and the rights management choice
% made by the author, this may be copyright transfer, permission,
% license, or an OA (open access) agreement.

% Regardless of the rights management choice, the author will receive a
% copy of the completed rights form once it has been submitted. This
% form contains \LaTeX\ commands that must be copied into the source
% document. When the document source is compiled, these commands and
% their parameters add formatted text to several areas of the final
% document:
% \begin{itemize}
% \item the ``ACM Reference Format'' text on the first page.
% \item the ``rights management'' text on the first page.
% \item the conference information in the page header(s).
% \end{itemize}

% Rights information is unique to the work; if you are preparing several
% works for an event, make sure to use the correct set of commands with
% each of the works.

% The ACM Reference Format text is required for all articles over one
% page in length, and is optional for one-page articles (abstracts).

% \section{CCS Concepts and User-Defined Keywords}

% Two elements of the ``acmart'' document class provide powerful
% taxonomic tools for you to help readers find your work in an online
% search.

% The ACM Computing Classification System ---
% \url{https://www.acm.org/publications/class-2012} --- is a set of
% classifiers and concepts that describe the computing
% discipline. Authors can select entries from this classification
% system, via \url{https://dl.acm.org/ccs/ccs.cfm}, and generate the
% commands to be included in the \LaTeX\ source.

% User-defined keywords are a comma-separated list of words and phrases
% of the authors' choosing, providing a more flexible way of describing
% the research being presented.

% CCS concepts and user-defined keywords are required for for all
% articles over two pages in length, and are optional for one- and
% two-page articles (or abstracts).

% \section{Sectioning Commands}

% Your work should use standard \LaTeX\ sectioning commands:
% \verb|section|, \verb|subsection|, \verb|subsubsection|, and
% \verb|paragraph|. They should be numbered; do not remove the numbering
% from the commands.

% Simulating a sectioning command by setting the first word or words of
% a paragraph in boldface or italicized text is {\bfseries not allowed.}

% \section{Tables}

% The ``\verb|acmart|'' document class includes the ``\verb|booktabs|''
% package --- \url{https://ctan.org/pkg/booktabs} --- for preparing
% high-quality tables.

% Table captions are placed {\itshape above} the table.

% Because tables cannot be split across pages, the best placement for
% them is typically the top of the page nearest their initial cite.  To
% ensure this proper ``floating'' placement of tables, use the
% environment \textbf{table} to enclose the table's contents and the
% table caption.  The contents of the table itself must go in the
% \textbf{tabular} environment, to be aligned properly in rows and
% columns, with the desired horizontal and vertical rules.  Again,
% detailed instructions on \textbf{tabular} material are found in the
% \textit{\LaTeX\ User's Guide}.

% Immediately following this sentence is the point at which
% Table~\ref{tab:freq} is included in the input file; compare the
% placement of the table here with the table in the printed output of
% this document.

% \begin{table}
%   \caption{Frequency of Special Characters}
%   \label{tab:freq}
%   \begin{tabular}{ccl}
%     \toprule
%     Non-English or Math&Frequency&Comments\\
%     \midrule
%     \O & 1 in 1,000& For Swedish names\\
%     $\pi$ & 1 in 5& Common in math\\
%     \$ & 4 in 5 & Used in business\\
%     $\Psi^2_1$ & 1 in 40,000& Unexplained usage\\
%   \bottomrule
% \end{tabular}
% \end{table}

% To set a wider table, which takes up the whole width of the page's
% live area, use the environment \textbf{table*} to enclose the table's
% contents and the table caption.  As with a single-column table, this
% wide table will ``float'' to a location deemed more
% desirable. Immediately following this sentence is the point at which
% Table~\ref{tab:commands} is included in the input file; again, it is
% instructive to compare the placement of the table here with the table
% in the printed output of this document.

% \begin{table*}
%   \caption{Some Typical Commands}
%   \label{tab:commands}
%   \begin{tabular}{ccl}
%     \toprule
%     Command &A Number & Comments\\
%     \midrule
%     \texttt{{\char'134}author} & 100& Author \\
%     \texttt{{\char'134}table}& 300 & For tables\\
%     \texttt{{\char'134}table*}& 400& For wider tables\\
%     \bottomrule
%   \end{tabular}
% \end{table*}

% Always use midrule to separate table header rows from data rows, and
% use it only for this purpose. This enables assistive technologies to
% recognise table headers and support their users in navigating tables
% more easily.

% \section{Math Equations}
% You may want to display math equations in three distinct styles:
% inline, numbered or non-numbered display.  Each of the three are
% discussed in the next sections.

% \subsection{Inline (In-text) Equations}
% A formula that appears in the running text is called an inline or
% in-text formula.  It is produced by the \textbf{math} environment,
% which can be invoked with the usual
% \texttt{{\char'134}begin\,\ldots{\char'134}end} construction or with
% the short form \texttt{\$\,\ldots\$}. You can use any of the symbols
% and structures, from $\alpha$ to $\omega$, available in
% \LaTeX~~\cite{Lamport:LaTeX}; this section will simply show a few
% examples of in-text equations in context. Notice how this equation:
% \begin{math}
%   \lim_{n\rightarrow \infty}x=0
% \end{math},
% set here in in-line math style, looks slightly different when
% set in display style.  (See next section).

% \subsection{Display Equations}
% A numbered display equation---one set off by vertical space from the
% text and centered horizontally---is produced by the \textbf{equation}
% environment. An unnumbered display equation is produced by the
% \textbf{displaymath} environment.

% Again, in either environment, you can use any of the symbols and
% structures available in \LaTeX\@; this section will just give a couple
% of examples of display equations in context.  First, consider the
% equation, shown as an inline equation above:
% \begin{equation}
%   \lim_{n\rightarrow \infty}x=0
% \end{equation}
% Notice how it is formatted somewhat differently in
% the \textbf{displaymath}
% environment.  Now, we'll enter an unnumbered equation:
% \begin{displaymath}
%   \sum_{i=0}^{\infty} x + 1
% \end{displaymath}
% and follow it with another numbered equation:
% \begin{equation}
%   \sum_{i=0}^{\infty}x_i=\int_{0}^{\pi+2} f
% \end{equation}
% just to demonstrate \LaTeX's able handling of numbering.

% \section{Figures}

% The ``\verb|figure|'' environment should be used for figures. One or
% more images can be placed within a figure. If your figure contains
% third-party material, you must clearly identify it as such, as shown
% in the example below.
% % \begin{figure}[h]
% %   \centering
% %   \includegraphics[width=\linewidth]{sample-franklin}
% %   \caption{1907 Franklin Model D roadster. Photograph by Harris \&
% %     Ewing, Inc. [Public domain], via Wikimedia
% %     Commons. (\url{https://goo.gl/VLCRBB}).}
% %   \Description{A woman and a girl in white dresses sit in an open car.}
% % \end{figure}

% Your figures should contain a caption which describes the figure to
% the reader.

% Figure captions are placed {\itshape below} the figure.

% Every figure should also have a figure description unless it is purely
% decorative. These descriptions convey what’s in the image to someone
% who cannot see it. They are also used by search engine crawlers for
% indexing images, and when images cannot be loaded.

% A figure description must be unformatted plain text less than 2000
% characters long (including spaces).  {\bfseries Figure descriptions
%   should not repeat the figure caption – their purpose is to capture
%   important information that is not already provided in the caption or
%   the main text of the paper.} For figures that convey important and
% complex new information, a short text description may not be
% adequate. More complex alternative descriptions can be placed in an
% appendix and referenced in a short figure description. For example,
% provide a data table capturing the information in a bar chart, or a
% structured list representing a graph.  For additional information
% regarding how best to write figure descriptions and why doing this is
% so important, please see
% \url{https://www.acm.org/publications/taps/describing-figures/}.

% \subsection{The ``Teaser Figure''}

% A ``teaser figure'' is an image, or set of images in one figure, that
% are placed after all author and affiliation information, and before
% the body of the article, spanning the page. If you wish to have such a
% figure in your article, place the command immediately before the
% \verb|\maketitle| command:
% % \begin{verbatim}
% %   \begin{teaserfigure}
% %     \includegraphics[width=\textwidth]{sampleteaser}
% %     \caption{figure caption}
% %     \Description{figure description}
% %   \end{teaserfigure}
% % \end{verbatim}

% \section{Citations and Bibliographies}

% The use of \BibTeX\ for the preparation and formatting of one's
% references is strongly recommended. Authors' names should be complete
% --- use full first names (``Donald E. Knuth'') not initials
% (``D. E. Knuth'') --- and the salient identifying features of a
% reference should be included: title, year, volume, number, pages,
% article DOI, etc.

% The bibliography is included in your source document with these two
% commands, placed just before the \verb|\end{document}| command:
% \begin{verbatim}
%   \bibliographystyle{ACM-Reference-Format}
%   \bibliography{bibfile}
% \end{verbatim}
% where ``\verb|bibfile|'' is the name, without the ``\verb|.bib|''
% suffix, of the \BibTeX\ file.

% Citations and references are numbered by default. A small number of
% ACM publications have citations and references formatted in the
% ``author year'' style; for these exceptions, please include this
% command in the {\bfseries preamble} (before the command
% ``\verb|\begin{document}|'') of your \LaTeX\ source:
% \begin{verbatim}
%   ~\citestyle{acmauthoryear}
% \end{verbatim}


%   Some examples.  A paginated journal article ~\cite{Abril07}, an
%   enumerated journal article ~\cite{Cohen07}, a reference to an entire
%   issue ~\cite{JCohen96}, a monograph (whole book) ~\cite{Kosiur01}, a
%   monograph/whole book in a series (see 2a in spec. document)
%   ~\cite{Harel79}, a divisible-book such as an anthology or compilation
%   ~\cite{Editor00} followed by the same example, however we only output
%   the series if the volume number is given ~\cite{Editor00a} (so
%   Editor00a's series should NOT be present since it has no vol. no.),
%   a chapter in a divisible book ~\cite{Spector90}, a chapter in a
%   divisible book in a series ~\cite{Douglass98}, a multi-volume work as
%   book ~\cite{Knuth97}, a couple of articles in a proceedings (of a
%   conference, symposium, workshop for example) (paginated proceedings
%   article) ~\cite{Andler79, Hagerup1993}, a proceedings article with
%   all possible elements ~\cite{Smith10}, an example of an enumerated
%   proceedings article ~\cite{VanGundy07}, an informally published work
%   ~\cite{Harel78}, a couple of preprints ~\cite{Bornmann2019,
%     AnzarootPBM14}, a doctoral dissertation ~\cite{Clarkson85}, a
%   master's thesis: ~\cite{anisi03}, an online document / world wide web
%   resource ~\cite{Thornburg01, Ablamowicz07, Poker06}, a video game
%   (Case 1) ~\cite{Obama08} and (Case 2) ~\cite{Novak03} and ~\cite{Lee05}
%   and (Case 3) a patent ~\cite{JoeScientist001}, work accepted for
%   publication ~\cite{rous08}, 'YYYYb'-test for prolific author
%   ~\cite{SaeediMEJ10} and ~\cite{SaeediJETC10}. Other cites might
%   contain 'duplicate' DOI and URLs (some SIAM articles)
%   ~\cite{Kirschmer:2010:AEI:1958016.1958018}. Boris / Barbara Beeton:
%   multi-volume works as books ~\cite{MR781536} and ~\cite{MR781537}. A
%   couple of citations with DOIs:
%   ~\cite{2004:ITE:1009386.1010128,Kirschmer:2010:AEI:1958016.1958018}. Online
%   citations: ~\cite{TUGInstmem, Thornburg01, CTANacmart}.
%   Artifacts: ~\cite{R} and ~\cite{UMassCitations}.

% \section{Acknowledgments}

% Identification of funding sources and other support, and thanks to
% individuals and groups that assisted in the research and the
% preparation of the work should be included in an acknowledgment
% section, which is placed just before the reference section in your
% document.

% This section has a special environment:
% \begin{verbatim}
%   \begin{acks}
%   ...
%   \end{acks}
% \end{verbatim}
% so that the information contained therein can be more easily collected
% during the article metadata extraction phase, and to ensure
% consistency in the spelling of the section heading.

% Authors should not prepare this section as a numbered or unnumbered {\verb|\section|}; please use the ``{\verb|acks|}'' environment.

% \section{Appendices}

% If your work needs an appendix, add it before the
% ``\verb|\end{document}|'' command at the conclusion of your source
% document.

% Start the appendix with the ``\verb|appendix|'' command:
% \begin{verbatim}
%   \appendix
% \end{verbatim}
% and note that in the appendix, sections are lettered, not
% numbered. This document has two appendices, demonstrating the section
% and subsection identification method.

% \section{Multi-language papers}

% Papers may be written in languages other than English or include
% titles, subtitles, keywords and abstracts in different languages (as a
% rule, a paper in a language other than English should include an
% English title and an English abstract).  Use \verb|language=...| for
% every language used in the paper.  The last language indicated is the
% main language of the paper.  For example, a French paper with
% additional titles and abstracts in English and German may start with
% the following command
% \begin{verbatim}
% \documentclass[sigconf, language=english, language=german,
%                language=french]{acmart}
% \end{verbatim}

% The title, subtitle, keywords and abstract will be typeset in the main
% language of the paper.  The commands \verb|\translatedXXX|, \verb|XXX|
% begin title, subtitle and keywords, can be used to set these elements
% in the other languages.  The environment \verb|translatedabstract| is
% used to set the translation of the abstract.  These commands and
% environment have a mandatory first argument: the language of the
% second argument.  See \verb|sample-sigconf-i13n.tex| file for examples
% of their usage.

% \section{SIGCHI Extended Abstracts}

% The ``\verb|sigchi-a|'' template style (available only in \LaTeX\ and
% not in Word) produces a landscape-orientation formatted article, with
% a wide left margin. Three environments are available for use with the
% ``\verb|sigchi-a|'' template style, and produce formatted output in
% the margin:
% \begin{description}
% \item[\texttt{sidebar}:]  Place formatted text in the margin.
% \item[\texttt{marginfigure}:] Place a figure in the margin.
% \item[\texttt{margintable}:] Place a table in the margin.
% \end{description}

% %%
% %% The acknowledgments section is defined using the "acks" environment
% %% (and NOT an unnumbered section). This ensures the proper
% %% identification of the section in the article metadata, and the
% %% consistent spelling of the heading.
% \begin{acks}
% To Robert, for the bagels and explaining CMYK and color spaces.
% \end{acks}

% %%
% %% The next two lines define the bibliography style to be used, and
% %% the bibliography file.
% \bibliographystyle{ACM-Reference-Format}
% \bibliography{sample-base}


% %%
% %% If your work has an appendix, this is the place to put it.
% \appendix

% \section{Research Methods}

% \subsection{Part One}

% Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi
% malesuada, quam in pulvinar varius, metus nunc fermentum urna, id
% sollicitudin purus odio sit amet enim. Aliquam ullamcorper eu ipsum
% vel mollis. Curabitur quis dictum nisl. Phasellus vel semper risus, et
% lacinia dolor. Integer ultricies commodo sem nec semper.

% \subsection{Part Two}

% Etiam commodo feugiat nisl pulvinar pellentesque. Etiam auctor sodales
% ligula, non varius nibh pulvinar semper. Suspendisse nec lectus non
% ipsum convallis congue hendrerit vitae sapien. Donec at laoreet
% eros. Vivamus non purus placerat, scelerisque diam eu, cursus
% ante. Etiam aliquam tortor auctor efficitur mattis.

% \section{Online Resources}

% Nam id fermentum dui. Suspendisse sagittis tortor a nulla mollis, in
% pulvinar ex pretium. Sed interdum orci quis metus euismod, et sagittis
% enim maximus. Vestibulum gravida massa ut felis suscipit
% congue. Quisque mattis elit a risus ultrices commodo venenatis eget
% dui. Etiam sagittis eleifend elementum.

% Nam interdum magna at lectus dignissim, ac dignissim lorem
% rhoncus. Maecenas eu arcu ac neque placerat aliquam. Nunc pulvinar
% massa et mattis lacinia.

% \bibliographystyle{unsrtnat}
\bibliographystyle{apa}
\bibliography{paperReferences}

\end{document}
\endinput
%%
%% End of file `sample-sigconf-authordraft.tex'.