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}

\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 Address Translations}

%%
%% 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.
\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
applications handle increasingly complex workloads. Memory management is a key factor
in performance, where efficient use of resources is essential. Translation Lookaside
Buffers (TLBs) are crucial in this context, speeding up memory access by caching recent
memory address translations. A TLB, a specialised cache in the memory management unit (MMU),
reduces the time required to convert virtual addresses to physical ones. When a program accesses
data in memory, the MMU first checks the TLB for a matching entry, avoiding the slower process of
consulting page tables. However, as applications grow larger and more complex, the fixed size of
TLBs often cannot keep up, leading to more TLB misses and 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. By reducing the number of TLB entries needed to access a given amount
of memory, Huge pages offer a potential avenue for optimising TLB utilisation 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. By 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.

Simultaneously, advancements in hardware-level security, such as the Capability Hardware Enhanced RISC Instructions (CHERI)
~\cite{woodruff_cheri_2014} 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 opens avenues for optimising memory management
operations. By integrating CHERI’s compressed encoded bounds~\cite{woodruff_cheri_2019} with the use of huge pages, We have shown   it is possible to track and manage
large, physically contiguous memory blocks without requiring numerous TLB entries. This combination reduces TLB pressure by minimising the number of
entries required to map extensive memory regions, thereby decreasing TLB misses and improving address translation performance.
Furthermore, it accelerates memory-intensive tasks by reducing the overhead associated with managing non-contiguous
memory allocations. The contributions for the following paper are as follows:
\begin{itemize}
  \item \textbf{Fat Addresses Translations}: Introduces fat-pointers that include memory bounds, allowing
  efficient tracking and management of physically contiguous memory regions (section ~\ref{sec:FatPointerTranslations}).

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

  \item \textbf{Memory Allocation Algorithms}: Provides new algorithms for allocating and freeing
  physically contiguous memory, integrating huge pages with CHERI's capability-based bounds for enhanced memory management
  (section ~\ref{sec:MemoryAllocator}).
\end{itemize} 

Through comprehensive evaluation, including micro and macro benchmarks, we demonstrate the allocator’s ability
to reduce TLB misses by up to 90\%, yielding significant improvements in wall clock runtimes for memory-intensive
applications. While its impact on larger, computation-heavy workloads is less pronounced,
the proposed allocator shows strong potential for advancing memory management in scenarios requiring
high memory throughput and low 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 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, backed by OS mechanisms like Transparent Huge Pages (THP)~\cite{THP}
and HugeTLBFS in Linux. 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, but using a 2 MB huge page would waste
half of the memory space. Some architectures offer more page size choices, such as Intel Itanium, which
allows different areas of the address space to have their own page sizes. Itanium uses a hash page table to organize huge
pages, but without significant changes to the conventional page table, it only helps reduce page walk overheads.
HP Tunable Base Page Size permits the OS to adjust the base page size, but still faces internal fragmentation problems,
with HP 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, 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 in certain scenarios.
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{Range 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, creating ranges that
are both virtually and physically contiguous. This approach simplifies address translation
within these ranges by adding an offset, similar to Direct Segment, but RMM supports multiple
ranges and operates transparently to programmers, requiring no source code modifications.
The range table, 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, a process that is computationally expensive and therefore performed
only after an L1 TLB miss. To optimize this, RMM uses a range TLB (RTLB) to quickly identify
if an address falls within any pre-allocated range, facilitating efficient translation and
reducing overhead. Range mapping works alongside the paging system by generating TLB entries on
TLB misses and still performing TLB lookups for each virtual address translation.
Unlike traditional segmentation mechanisms, range mapping activates a range lookaside
buffer (RTLB) located with the last level TLB upon a miss. The hardware TLB miss
handler then searches the RTLB for the miss address and, if found, generates a new
TLB entry with the physical address derived from the base virtual address and
range offset, along with 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 in the background, avoiding delays in memory operations.
The RTLB, functioning as a fully associative search structure, ensures
that most last level TLB misses are handled efficiently by range mapping,
reducing the need for costly page table walks.

\subsection{CHERI}
\label{sec:orgbf2eaac}
CHERI (Capability Hardware Enhanced RISC Instructions) 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}


\section{Fat Address Translations}
\label{sec:FatPointerTranslations}
This section talks about how Fat-pointer Address Translations uses the CHERI architecture to
bring about block based allocations in physically contiguous memory. Fat-pointer Address Translations
leverages techniques like FlexPointer~\cite{chen_flexpointer_2023} and Range Memory Mapping (RMM)~\cite{karakostas_redundant_2015} to 
achieve lesser pressure in 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*}[h]
  \includegraphics[width=0.6\textwidth]{diagram/HighOverviewArchitecture.drawio.png}
  \caption{High overview architecture}
  \label{fig:HighOverviewArchitecture}
% \end{minipage}
\end{figure*}

Figure \ref{fig:HighOverviewArchitecture} illustrates a comparison between standard memory allocation (malloc()) and a proposed Fat-pointer Address
Translation method. The standard approach involves a C program interacting with a custom allocator, utilizing 48-bit 
free virtual addresses and a TLB walk (L1, L2, L3) 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-pointer Address Translations method employs a custom allocator leveraging 
physically contiguous memory by using CHERI to encode 
bounds within the pointers and as show in the figure \ref{fig:HighOverviewArchitecture} there is almost no reliance on walking the TLB. 

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}
\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. 
In this implementation, memory ranges are established using
bounds encoded within the FAT-pointer, adhering to the CHERI
CHERI 128-bit bounds compression scheme~\cite{woodruff_cheri_2019}.

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 malloc twice to allocate memory in distinct regions.
This scenario simulates a block-based memory allocator operating within the confines of the huge page.
The allocations use the bounds encoded in the FAT-pointer, ensuring tracking of the allocated memory regions. 
By using the CHERI bounds, this method maintains the contiguity of the allocated blocks within the huge page.

\subsection{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.

We use CHERI CC~\cite{woodruff_cheri_2019} (Compressed Capabilities) 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 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.

One key analysis of CHERI CC highlights that 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~\cite{woodruff_cheri_2019} to store the
exponent values within compressed bounds.

This means that the default behavior of allocators such as Jemalloc, would allow precise
representation of bounds within CHERI CC. With our implementation rather than using 
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-pointer Address Translations using huge pages}
  \label{fig:HugePages}
\end{figure}
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, Our approach
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 Based Address 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 a sample access to read within a contigous
space of physical memory. The dotted lines represents the
bounds for that particular pointer access. Using bounds
stored on the pointer a block based pattern can be reprecated
on physically contigous memory.

\section{Memory allocator design}
\label{sec:MemoryAllocator}
This section presents a straightforward memory allocator designed and implemented based on the
principles outlined in our approach. The allocator consists of three core functions: InitAlloc,
malloc, and free. The InitAlloc function initializes the memory pool, setting up the necessary
data structures and metadata required for efficient memory management. The malloc function is
responsible for allocating a contiguous block of memory of a specified size, while the free
function deallocates the memory, returning it 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 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, which constructs a FAT-pointer specialized
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 malloc. This
approach introduces a method of memory tracking, where the bounds of the allocated region are
explicitly encoded in the address, enabling efficient monitoring and management of memory usage.

Furthermore, this design uses shared 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 enhancing safety and reducing the risk of out-of-bounds
errors. This use of FAT-pointers and shared TLB entries not only aligns with the principles of
efficient memory management but also demonstrates a practical usecase 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-pointer structure
  introduced in the malloc algorithm. When the free function is invoked, it utilizes the metadata
  embedded within the FAT-pointer to determine the range and size of the allocated memory region.
  Specifically, the start and end addresses encoded in the FAT-pointer provide the necessary information
  to identify the exact memory block to be deallocated. This allows the allocator to precisely unmap
  the corresponding memory region from the address space, ensuring efficient and accurate memory management.

  By extracting the bounds and size directly from the FAT-pointer, the 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 initialization of physically contiguous memory through the use of huge pages,
a mechanism supported by modern architectures to optimize memory management. The algorithm begins by
allocating a fixed block of 1 GB of 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 efficiency, which is critical for performance-sensitive
applications and kernel-level operations.

\section{Evaluation}
We conducted tests of the FAT Pointer-based range addresses against Jemalloc~\cite{jemalloc},
the default memory allocator for CHERIBSD~\cite{cheribsd}, to assess the performance improvements
enabled by a CHERI-based huge page-aware allocator. Specifically, we evaluated
the reduction in TLB walks and misses and its impact on wall clock runtime.

To comprehensively analyze the proposed allocator, we categorized benchmarks into
two classes which are micro and macro benchmarks. Micro benchmarks comprise smaller
C programs designed to target specific allocator patterns, enabling us to evaluate
detailed aspects of the allocator's behavior. Macro benchmarks, on the other hand,
encompass larger, real-world C programs, allowing us to assess the allocator's
performance in more practical, real-world scenarios.

The experiment setup section 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
focused on particular allocation and deallocation patterns, such as sequential and
random memory accesses, to stress-test the allocator under controlled conditions.
Macro benchmarks 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 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, 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. These
limitations provide a roadmap for future optimizations and refinements of the allocator design.

\subsection{Experiment setup}
The CHERI Morello~\cite{Morello} board was used to evaluate the proposed memory allocator.
Morello implements the ARM A76 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, ensuring compatibility with CHERI's capability-based
memory model. When compiling the C programs for benchmarking, the Benchmark ABI was
used as recommended by the CHERI community. This compilation mode was enabled using
the Clang compiler.

The Benchmark ABI~\cite{BenchmarkABI} 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 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 modified C allocator, imported as a header file. This approach was necessary
because the Benchmark ABI shared object file exhibited unexpected behavior,
failing to overwrite the C program at runtime with the intended malloc functions.
The second allocator was the standard OS memory allocator, which, in the case of
CHERIBSD, is Jemalloc.

Performance measurements were carried out using ARM 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/cpu\_cycles) CPU cycles & The CPU CYCLES counter increases with \\
   & every clock cycle. However, it can be \\
   & affected by changes in clock frequency, \\
   & such as when WFI (Wait for Interrupt) \\
   & or WFE (Wait for Event) \\
   & instructions pause the clock. \\
   & \\
  (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}
  \end{table*}

\subsection{Benchmarks}
The benchmarks~\cite{Benchmark} are classified into 2 classes:

\subsubsection{Micro benchmark}
  \label{sec:org41c278c}
  \begin{itemize}
  \item GLIBC: The Glibc benchmark evaluates the performance of
  malloc and free functions in single-threaded, multi-threaded,
  and emulated multi-threading scenarios using various block sizes and
  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 analyze performance variations.
  \item MemAccess: This benchmark by Alex Bordei 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
  randomized structures, optional node operations, and multithreaded
  traversal using pthreads. The program dynamically allocates memory and systematically
  doubles the working set size to analyze memory hierarchy behavior.
  \end{itemize}

\subsubsection{Macro benchmark}
\label{sec:org89020f2}
\begin{itemize}
\item Kmeans: Kmeans implements a parallelized K-means clustering algorithm that
assigns data points to clusters based on proximity to centroids,
iteratively updating them until convergence. The computation is
distributed across threads using the pthread library, dynamically
assigning tasks to optimize performance. Parameters like data size
and clusters are configurable, and the program ensures efficient
memory management and synchronization.
\item Richards: Richards is a task scheduling benchmark that simulates a
multitasking environment with tasks of varying types and priorities,
communicating through queued packets. The schedule function manages
task execution based on state and priority, tracking processed packets
and held tasks for performance evaluation. Configurable iterations and
timing help measure system performance and ensure correctness.
\end{itemize}


\subsection{Results}
\begin{figure*}[h]
\includegraphics[width=.9\linewidth]{diagram/bargraph.png}
\caption{\label{fig:bargraph}Percentage difference between the modified memory allocator against the default system memory allocator}
\end{figure*}

The graph (Figure \ref{fig:bargraph}) highlights the performance comparison between the modified memory allocator and
Jemalloc, the default memory allocator. The FAT pointer memory allocator, specifically optimized
for use with huge pages, 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.

<points metric based>
     - Each benchmark reflection for the metric
     - summary based on each benchmark reflected

- summarize all the bullet points.

A particularly striking observation is the significant reduction in data TLB walks,
L2 data TLB reads, and TLB refills—consistently showing a 90\% decrease across all
benchmarks compared to Jemalloc. This improvement is due to the modified allocator's
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 allocator's
superior performance for certain types of workloads.

The micro benchmarks, which are crafted to emphasize memory read operations, highlight the
allocator's strengths. These tests simulate frequent and intensive memory access patterns,
where the reduction in TLB misses directly translates into measurable performance gains.
On average, the FAT pointer allocator achieves a 50\% reduction in wall clock runtimes for
these workloads, underscoring its ability to optimize 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 pointer allocator.
This outcome is expected, as macro benchmarks typically involve a broader range of operations
beyond memory allocation, diluting the impact of the allocator's optimizations. 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 to evaluate the performance difference
  between the FAT pointer allocator and the baseline allocator as the workload scales. This analysis
  aims to understand how the allocator's optimizations, 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 allocator's 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 allocator's ability to minimize 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 2000, 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 pointer 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 allocator's
optimizations.

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{Usability}
\label{sec:orgd6ba6f0}
The FAT pointer memory allocator demonstrates significant potential for enhancing
memory management in systems that benefit from huge page optimizations. Its design
effectively reduces TLB misses, achieving up to 90\% fewer data TLB walks, L2 TLB reads,
and TLB refills compared to 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-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 allocator's interaction with system-level caching and memory translation mechanisms.

While the allocator excels in scenarios emphasizing 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 those constrained by
computation or I/O bottlenecks.

\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 addresses the growing disparity between application workloads and the capacity of TLBs.
To mitigate this gap, we proposed leveraging physically contiguous memory with CHERI bounds to reduce TLB walks. 
We designed a memory allocator which uses huge pages with CHERI CC scheme to track allocations within the 
allocated huge page. This approach has helped reduce the number of TLB entries needed while using bounds
to minimize 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
Comprehensive benchmarking demonstrates that the allocator reduces TLB misses by up to 90\%,
leading to substantial performance gains in memory-intensive workloads, though the improvements are less pronounced
for larger, computation-heavy applications. These results highlight the allocator's potential to advance memory management
by combining enhanced security and performance through 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{unsrt}
\bibliography{paperReferences}

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