Cheri-research/FAT-Allocator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

added content for Jemalloc

Browse Source
This commit is contained in:
Akilan Selvacoumar
2025-05-29 23:32:46 +01:00
parent f3401de543
commit 0bd28d57d1
8 changed files with 283 additions and 151 deletions
Download Patch File Download Diff File Expand all files Collapse all files

99
docs/EuroSys/Paper/jemalloc.org Normal file
View File

@@ -0,0 +1,99 @@
* Malloc
The provided pseudocode outlines a modified implementation
of jemalloc’s memory mapping routines, adapted to work with
a custom malloc(sz) allocator. Instead of relying on traditional
operating system mechanisms like mmap, the memory allocation is
handled using MALLOC(size)
-> refer pseudo code implementation.
which refers to a simplified allocator
defined earlier. This custom allocator manages a preallocated
memory region, aligns the requested size, decrements a memory
counter, and returns a pointer with enforced bounds for memory
safety. This approach is especially suited for constrained or
security-focused environments such as CHERI, where strict
control over memory access and deterministic allocation
behavior is essential.
The os_pages_map function simulates jemalloc’s low-level page
mapping routine. It first checks if a specific address is
requested in case relevant to CheriABI where such behavior
is disallowed and returns NULL.
If memory overcommitment
is allowed it forces the commit flag to true.
It then allocates memory using the custom MALLOC(size) function and validates
whether the returned pointer matches the requested address
(if one was provided). If there’s a mismatch, it unmaps (i.e calling FREE() -> ref algorithm) the
memory and returns NULL; otherwise, it returns the allocated
pointer.
The pages_map function is a simplified variant that ignores
alignment and address constraints. It directly allocates the
requested memory size using the internal allocator and returns
the result. This is appropriate in scenarios where alignment is
either managed elsewhere or not critical.
This approach mentioned above is embeded inside jemallocs strategy of managing memory through arenas and size 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 (source: http://hydra.azilian.net/Papers/jemalloc.pdf)
Not needed:
The pages_commit_impl function emulates memory commitment, a
feature in systems that support lazy memory allocation. It
reallocates memory using MALLOC(size) and checks whether
the returned pointer matches the expected address. If not,
it unmaps the memory and signals failure by returning true;
otherwise, it indicates success by returning false.
Not needed:
Collectively, these routines demonstrate how jemalloc can be
adapted to operate atop a custom memory allocator instead of
relying on the OS. This enables jemalloc to function in
specialized environments that require stricter memory controls,
such as embedded systems or capability-based architectures,
while still maintaining its structure and allocation policies.
* Free
The os_pages_unmap algorithm 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) -> Point to algorithm implementation
Not needed:
routine, which encapsulates memory management
within a user-defined allocator, rather than relying on direct interaction with the
operating system.
The function begins by enforcing two invariants through assertions: first, that the input
address addr is aligned to the operating system's page size (os_page), 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) operation. As previously defined in the free(ptr) pseudocode, this involves
retrieving the size of the allocated region through bounds metadata
(reference section) and invoking an internal unmap routine to mark the region
as available.
The following changes done to free is embedded inside jemallocs 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.
Not needed:
This design enables jemalloc to operate seamlessly in environments where
standard system-level memory operations are either restricted or abstracted away, such
as in sandboxed, embedded, or capability-based systems like CHERI.
Not needed:
Overall, this approach demonstrates how jemalloc’s modular architecture can be extended
to support alternative memory management strategies. By redirecting low-level memory
operations to custom allocators, developers can adapt jemalloc to function effectively
in constrained or security-critical execution contexts, without compromising on its
underlying allocation model or safety guarantees.

43
docs/EuroSys/Paper/jemalloc.org~ Normal file
View File

@@ -0,0 +1,43 @@
The provided pseudocode outlines a modified implementation
of jemalloc’s memory mapping routines, adapted to work with
a custom malloc(sz) allocator. Instead of relying on traditional
operating system mechanisms like mmap, the memory allocation is
handled using MALLOC(size), which refers to a simplified allocator
defined earlier. This custom allocator manages a preallocated
memory region, aligns the requested size, decrements a memory
counter, and returns a pointer with enforced bounds for memory
safety. This approach is especially suited for constrained or
security-focused environments such as CHERI, where strict
control over memory access and deterministic allocation
behavior is essential.
The os_pages_map function simulates jemalloc’s low-level page
mapping routine. It first checks if a specific address is
requested—a case relevant to CheriABI where such behavior
is disallowed—and returns NULL if so. If memory overcommitment
is allowed, it forces the commit flag to true. It then allocates
memory using the custom MALLOC(size) function and validates
whether the returned pointer matches the requested address
(if one was provided). If there’s a mismatch, it unmaps the
memory and returns NULL; otherwise, it returns the allocated
pointer.
The pages_map function is a simplified variant that ignores
alignment and address constraints. It directly allocates the
requested memory size using the internal allocator and returns
the result. This is appropriate in scenarios where alignment is
either managed elsewhere or not critical.
The pages_commit_impl function emulates memory commitment, a
feature in systems that support lazy memory allocation. It
reallocates memory using MALLOC(size) and checks whether
the returned pointer matches the expected address. If not,
it unmaps the memory and signals failure by returning true;
otherwise, it indicates success by returning false.
Collectively, these routines demonstrate how jemalloc can be
adapted to operate atop a custom memory allocator instead of
relying on the OS. This enables jemalloc to function in
specialized environments that require stricter memory controls,
such as embedded systems or capability-based architectures,
while still maintaining its structure and allocation policies.

32
docs/EuroSys/Paper/paper.aux
View File

@@ -41,12 +41,10 @@
\@writefile{toc}{\contentsline {section}{\numberline {4}128 bit compressed bounds}{3}{section.4}\protected@file@percent }
\newlabel{sec:128bitCompressedBounds}{{4}{3}{128 bit compressed bounds}{section.4}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {4.1}Instrumenting Block-Based Allocators with Physically Contiguous Memory}{3}{subsection.4.1}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{\numberline {5}Memory allocator design}{3}{section.5}\protected@file@percent }
\newlabel{sec:MemoryAllocator}{{5}{3}{Memory allocator design}{section.5}{}}
\citation{jemalloc}
\citation{cheribsd}
\citation{Benchmark}
\citation{Morello}
\@writefile{toc}{\contentsline {section}{\numberline {5}Memory allocator design}{4}{section.5}\protected@file@percent }
\newlabel{sec:MemoryAllocator}{{5}{4}{Memory allocator design}{section.5}{}}
\@writefile{loa}{\contentsline {algorithm}{\numberline {1}{\ignorespaces Malloc implementation}}{4}{algorithm.1}\protected@file@percent }
\newlabel{alg:malloc}{{1}{4}{Malloc implementation}{algorithm.1}{}}
\@writefile{loa}{\contentsline {algorithm}{\numberline {2}{\ignorespaces Free implementation}}{4}{algorithm.2}\protected@file@percent }
@@ -54,14 +52,18 @@
\@writefile{loa}{\contentsline {algorithm}{\numberline {3}{\ignorespaces Init alloc function to create a initial 1 GB huge page}}{4}{algorithm.3}\protected@file@percent }
\newlabel{alg:initAlloc}{{3}{4}{Init alloc function to create a initial 1 GB huge page}{algorithm.3}{}}
\@writefile{toc}{\contentsline {section}{\numberline {6}Embedding FAT allocator inside Jemalloc}{4}{section.6}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{\numberline {7}Evaluation}{4}{section.7}\protected@file@percent }
\newlabel{sec:Evaluation}{{7}{4}{Evaluation}{section.7}{}}
\@writefile{loa}{\contentsline {algorithm}{\numberline {4}{\ignorespaces Modified Jemalloc Memory Mapping Routines}}{4}{algorithm.4}\protected@file@percent }
\newlabel{alg:JemallocMalloc}{{4}{4}{Modified Jemalloc Memory Mapping Routines}{algorithm.4}{}}
\citation{Benchmark}
\citation{Morello}
\citation{BenchmarkABI}
\citation{PerformanceCounter}
\@writefile{loa}{\contentsline {algorithm}{\numberline {4}{\ignorespaces Modified Jemalloc Memory Mapping Routines}}{5}{algorithm.4}\protected@file@percent }
\newlabel{alg:JemallocMalloc}{{4}{5}{Modified Jemalloc Memory Mapping Routines}{algorithm.4}{}}
\citation{singh1993}
\citation{holt1995}
\newlabel{alg:JemallocFree}{{\caption@xref {alg:JemallocFree}{ on input line 827}}{5}{Embedding FAT allocator inside Jemalloc}{algorithm.4}{}}
\@writefile{loa}{\contentsline {algorithm}{\numberline {5}{\ignorespaces os\_pages\_unmap}}{5}{algorithm.5}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{\numberline {7}Evaluation}{5}{section.7}\protected@file@percent }
\newlabel{sec:Evaluation}{{7}{5}{Evaluation}{section.7}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {7.1}Experiment setup}{5}{subsection.7.1}\protected@file@percent }
\newlabel{sec:Experiment}{{7.1}{5}{Experiment setup}{subsection.7.1}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {7.2}Benchmarks}{5}{subsection.7.2}\protected@file@percent }
@@ -69,10 +71,8 @@
\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.2.1}Micro benchmark}{5}{subsubsection.7.2.1}\protected@file@percent }
\newlabel{sec:Macro}{{7.2.2}{5}{Macro benchmark}{subsubsection.7.2.2}{}}
\@writefile{toc}{\contentsline {subsubsection}{\numberline {7.2.2}Macro benchmark}{5}{subsubsection.7.2.2}\protected@file@percent }
\citation{singh1993}
\citation{holt1995}
\@writefile{toc}{\contentsline {subsection}{\numberline {7.3}Results}{6}{subsection.7.3}\protected@file@percent }
\newlabel{sec:Results}{{7.3}{6}{Results}{subsection.7.3}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {7.3}Results}{5}{subsection.7.3}\protected@file@percent }
\newlabel{sec:Results}{{7.3}{5}{Results}{subsection.7.3}{}}
\@writefile{lot}{\contentsline {table}{\numberline {1}{\ignorespaces ARM performance counters}}{6}{table.caption.4}\protected@file@percent }
\newlabel{tab:org246a883}{{1}{6}{ARM performance counters}{table.caption.4}{}}
\newlabel{table:ARMPerf}{{1}{6}{ARM performance counters}{table.caption.4}{}}
@@ -90,8 +90,6 @@
\newlabel{sub@fig:wallclock}{{f}{7}{Wall Clock Time}{figure.caption.5}{}}
\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces Benchmarks comparing the percentage difference between FAT.}}{7}{figure.caption.5}\protected@file@percent }
\newlabel{fig:benchmarks-group}{{2}{7}{Benchmarks comparing the percentage difference between FAT}{figure.caption.5}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {7.4}Analysis}{8}{subsection.7.4}\protected@file@percent }
\newlabel{sec:Analysis}{{7.4}{8}{Analysis}{subsection.7.4}{}}
\bibstyle{unsrtnat}
\bibdata{paperReferences}
\bibcite{TLBHierarchy}{{1}{2013}{{Lustig et~al.}}{{Lustig, Bhattacharjee, and Martonosi}}}
@@ -106,6 +104,10 @@
\bibcite{DirectSegment}{{10}{2013}{{Basu et~al.}}{{Basu, Gandhi, Chang, Hill, and Swift}}}
\bibcite{karakostas_redundant_2015}{{11}{}{{Karakostas et~al.}}{{Karakostas, Gandhi, Ayar, Cristal, Hill, {McKinley}, Nemirovsky, Swift, and Ünsal}}}
\bibcite{chen_flexpointer_2023}{{12}{2023}{{Chen et~al.}}{{Chen, Tong, Yang, Yi, and Cheng}}}
\@writefile{toc}{\contentsline {subsection}{\numberline {7.4}Analysis}{8}{subsection.7.4}\protected@file@percent }
\newlabel{sec:Analysis}{{7.4}{8}{Analysis}{subsection.7.4}{}}
\@writefile{toc}{\contentsline {section}{\numberline {8}Conclusion}{8}{section.8}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{References}{8}{section*.7}\protected@file@percent }
\bibcite{jemalloc}{{13}{2006}{{Evans}}{{}}}
\bibcite{cheribsd}{{14}{}{{che}}{{}}}
\bibcite{Benchmark}{{15}{}{{Ben}}{{}}}
@@ -121,8 +123,6 @@
\newlabel{tocindent3}{18.198pt}
\newlabel{tocindent4}{0pt}
\newlabel{tocindent5}{0pt}
\@writefile{toc}{\contentsline {section}{\numberline {8}Conclusion}{9}{section.8}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{References}{9}{section*.7}\protected@file@percent }
\newlabel{TotPages}{{9}{9}{}{page.9}{}}
\gdef\svg@ink@ver@settings{{\m@ne }{inkscape}{\m@ne }}
\gdef \@abspage@last{9}

14
docs/EuroSys/Paper/paper.fdb_latexmk
View File

@@ -1,13 +1,13 @@
# Fdb version 4
["bibtex paper"] 1748298354.94538 "paper.aux" "paper.bbl" "paper" 1748298357.47654 0
["bibtex paper"] 1748542391.49982 "paper.aux" "paper.bbl" "paper" 1748542393.50586 0
"./paperReferences.bib" 1746971882.78313 50975 d23cf0e29e30a59879e0a43f7bd63014 ""
"/usr/local/texlive/2025/texmf-dist/bibtex/bst/natbib/unsrtnat.bst" 1233624470 24550 a41a6405f4de768c43e871d9fbce2bc8 ""
"paper.aux" 1748298357.087 9430 ccff33579246ecce72fa55d0a77e6d17 "pdflatex"
"paper.aux" 1748542393.18687 9430 f2d638c91d61664cb189252cfa34b0aa "pdflatex"
(generated)
"paper.bbl"
"paper.blg"
(rewritten before read)
["pdflatex"] 1748298355.05037 "paper.tex" "paper.pdf" "paper" 1748298357.47672 0
["pdflatex"] 1748542391.64154 "paper.tex" "paper.pdf" "paper" 1748542393.506 0
"/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/inconsolata/i4-t1-4.enc" 1558214095 7693 0f2dce6d313c82989ec3a67fc24df2a0 ""
"/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/libertine/lbtn_25tcsq.enc" 1490131464 2921 8ca0eb0831f9bc5da080d3697cfe67bf ""
"/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/libertine/lbtn_76gpa5.enc" 1490131464 2933 9ad527ce78d7c5fa0a642dead095f172 ""
@@ -254,10 +254,10 @@
"diagram/benchmarks-group/bargraph-large-ll-cache-rd.png" 1747839169.49301 52855 22a83d7bc1ca7dfa1c47f31936824ff6 ""
"diagram/benchmarks-group/bargraph-large-wallclock.png" 1747839751.63939 55378 1da56901d20a39a645beca6272b36eaf ""
"diagram/drawing_png.png" 1748297803.36134 22858 0c9dbeaa2b2a2c8d4588aeb499d141da ""
"paper.aux" 1748298357.087 9430 ccff33579246ecce72fa55d0a77e6d17 "pdflatex"
"paper.bbl" 1748298355.0467 8420 47d3ab73b727b7165b20d774bb45ad1a "bibtex paper"
"paper.out" 1748298357.08809 3482 dfb5cd2e0b64721769d9bbb90a3777d7 "pdflatex"
"paper.tex" 1748298348.19746 97986 3d168af49491944c70254477c1890880 ""
"paper.aux" 1748542393.18687 9430 f2d638c91d61664cb189252cfa34b0aa "pdflatex"
"paper.bbl" 1748542391.63845 8420 47d3ab73b727b7165b20d774bb45ad1a "bibtex paper"
"paper.out" 1748542393.18782 3482 dfb5cd2e0b64721769d9bbb90a3777d7 "pdflatex"
"paper.tex" 1748537227.43593 98923 e8aacff771f33802f685e767cf224fa6 ""
(generated)
"paper.aux"
"paper.log"

66
docs/EuroSys/Paper/paper.fls
View File

@@ -559,11 +559,11 @@ INPUT ./diagram/drawing_png.png
INPUT ./diagram/drawing_png.png
INPUT ./diagram/drawing_png.png
INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/libertine/LinLibertineTI-tlf-t1.tfm
INPUT /usr/local/texlive/2025/texmf-dist/fonts/vf/public/libertine/LinLibertineTI-tlf-t1.vf
INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/libertine/LinLibertineTI-tlf-t1--base.tfm
INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/libertine/LinLibertineT-tlf-sc-t1.tfm
INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/libertine/LinLibertineT-tlf-t1.tfm
INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/libertine/LinLibertineT-tlf-t1.tfm
INPUT /usr/local/texlive/2025/texmf-dist/fonts/vf/public/libertine/LinLibertineTI-tlf-t1.vf
INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/libertine/LinLibertineTI-tlf-t1--base.tfm
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/inconsolata/t1zi4.fd
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/inconsolata/t1zi4.fd
INPUT /usr/local/texlive/2025/texmf-dist/tex/latex/inconsolata/t1zi4.fd
@@ -578,44 +578,44 @@ INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/newtx/stxscr.tfm
INPUT /usr/local/texlive/2025/texmf-dist/fonts/vf/public/libertine/LinLibertineT-tlf-ot1.vf
INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/libertine/LinLibertineT-tlf-ot1--base.tfm
INPUT /usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/libertine/lbtn_oexx6f.enc
INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/libertine/LinBiolinumTI-tlf-t1.tfm
INPUT /usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/inconsolata/i4-t1-4.enc
INPUT /usr/local/texlive/2025/texmf-dist/fonts/vf/public/newtx/nxlmia.vf
INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/newtx/LibertineMathRM.tfm
INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/newtx/txmiaSTbb.tfm
INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/newtx/txmiaX.tfm
INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/libertine/LinBiolinumTI-tlf-t1.tfm
INPUT ./diagram/benchmarks-group/bargraph-large-dtlb-walk.png
INPUT ./diagram/benchmarks-group/bargraph-large-dtlb-walk.png
INPUT ./diagram/benchmarks-group/bargraph-large-dtlb-walk.png
INPUT ./diagram/benchmarks-group/bargraph-large-dtlb-walk.png
INPUT ./diagram/benchmarks-group/bargraph-large-dtlb-walk.png
INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-reads.png
INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-reads.png
INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-reads.png
INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-reads.png
INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-reads.png
INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-refill.png
INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-refill.png
INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-refill.png
INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-refill.png
INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-refill.png
INPUT ./diagram/benchmarks-group/bargraph-large-l2tlb-reads.png
INPUT ./diagram/benchmarks-group/bargraph-large-l2tlb-reads.png
INPUT ./diagram/benchmarks-group/bargraph-large-l2tlb-reads.png
INPUT ./diagram/benchmarks-group/bargraph-large-l2tlb-reads.png
INPUT ./diagram/benchmarks-group/bargraph-large-l2tlb-reads.png
INPUT ./diagram/benchmarks-group/bargraph-large-ll-cache-rd.png
INPUT ./diagram/benchmarks-group/bargraph-large-ll-cache-rd.png
INPUT ./diagram/benchmarks-group/bargraph-large-ll-cache-rd.png
INPUT ./diagram/benchmarks-group/bargraph-large-ll-cache-rd.png
INPUT ./diagram/benchmarks-group/bargraph-large-ll-cache-rd.png
INPUT ./diagram/benchmarks-group/bargraph-large-wallclock.png
INPUT ./diagram/benchmarks-group/bargraph-large-wallclock.png
INPUT ./diagram/benchmarks-group/bargraph-large-wallclock.png
INPUT ./diagram/benchmarks-group/bargraph-large-wallclock.png
INPUT ./diagram/benchmarks-group/bargraph-large-wallclock.png
INPUT /usr/local/texlive/2025/texmf-dist/fonts/vf/public/libertine/LinBiolinumTI-tlf-t1.vf
INPUT /usr/local/texlive/2025/texmf-dist/fonts/tfm/public/libertine/LinBiolinumTI-tlf-t1--base.tfm
INPUT ./diagram/benchmarks-group/bargraph-large-dtlb-walk.png
INPUT ./diagram/benchmarks-group/bargraph-large-dtlb-walk.png
INPUT ./diagram/benchmarks-group/bargraph-large-dtlb-walk.png
INPUT ./diagram/benchmarks-group/bargraph-large-dtlb-walk.png
INPUT ./diagram/benchmarks-group/bargraph-large-dtlb-walk.png
INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-reads.png
INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-reads.png
INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-reads.png
INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-reads.png
INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-reads.png
INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-refill.png
INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-refill.png
INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-refill.png
INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-refill.png
INPUT ./diagram/benchmarks-group/bargraph-large-l1tlb-refill.png
INPUT ./diagram/benchmarks-group/bargraph-large-l2tlb-reads.png
INPUT ./diagram/benchmarks-group/bargraph-large-l2tlb-reads.png
INPUT ./diagram/benchmarks-group/bargraph-large-l2tlb-reads.png
INPUT ./diagram/benchmarks-group/bargraph-large-l2tlb-reads.png
INPUT ./diagram/benchmarks-group/bargraph-large-l2tlb-reads.png
INPUT ./diagram/benchmarks-group/bargraph-large-ll-cache-rd.png
INPUT ./diagram/benchmarks-group/bargraph-large-ll-cache-rd.png
INPUT ./diagram/benchmarks-group/bargraph-large-ll-cache-rd.png
INPUT ./diagram/benchmarks-group/bargraph-large-ll-cache-rd.png
INPUT ./diagram/benchmarks-group/bargraph-large-ll-cache-rd.png
INPUT ./diagram/benchmarks-group/bargraph-large-wallclock.png
INPUT ./diagram/benchmarks-group/bargraph-large-wallclock.png
INPUT ./diagram/benchmarks-group/bargraph-large-wallclock.png
INPUT ./diagram/benchmarks-group/bargraph-large-wallclock.png
INPUT ./diagram/benchmarks-group/bargraph-large-wallclock.png
INPUT ./paper.bbl
INPUT ./paper.bbl
INPUT paper.bbl

76
docs/EuroSys/Paper/paper.log
View File

@@ -1,4 +1,4 @@
This is pdfTeX, Version 3.141592653-2.6-1.40.27 (TeX Live 2025) (preloaded format=pdflatex 2025.4.2) 26 MAY 2025 23:25
This is pdfTeX, Version 3.141592653-2.6-1.40.27 (TeX Live 2025) (preloaded format=pdflatex 2025.4.2) 29 MAY 2025 19:13
entering extended mode
\write18 enabled.
%&-line parsing enabled.
@@ -1509,20 +1509,6 @@ LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/it' will be
(Font) scaled to size 9.0pt on input line 534.
LaTeX Warning: Reference `fig:RangeOfMemory' on page 3 undefined on input line
571.
LaTeX Warning: Reference `fig:HugePages' on page 3 undefined on input line 665.
Underfull \vbox (badness 10000) has occurred while \output is active []
[3.3 <./diagram/drawing_png.png>]
Package hyperref Info: bookmark level for unknown algorithm defaults to 0 on in
put line 689.
LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/sc' will be
@@ -1533,6 +1519,8 @@ LaTeX Font Info: Font shape `T1/LinuxLibertineT-TLF/m/n' will be
(Font) scaled to size 5.5pt on input line 693.
[3.3 <./diagram/drawing_png.png>]
LaTeX Font Info: Trying to load font information for T1+zi4 on input line 77
7.
(/usr/local/texlive/2025/texmf-dist/tex/latex/inconsolata/t1zi4.fd
@@ -1569,15 +1557,15 @@ ory al-lo-ca-tor for CHERIBSD [[]].
[4.4{/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/libertine/lbtn_ncsllp.e
nc}{/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/libertine/lbtn_oexx6f.en
c}]
c}{/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/inconsolata/i4-t1-4.enc}]
Underfull \vbox (badness 5681) has occurred while \output is active []
LaTeX Font Info: Font shape `T1/LinuxBiolinumT-TLF/m/it' will be
(Font) scaled to size 9.0pt on input line 963.
[5.5{/usr/local/texlive/2025/texmf-dist/fonts/enc/dvips/inconsolata/i4-t1-4.enc
}]
<diagram/benchmarks-group/bargraph-large-dtlb-walk.png, id=208, 1011.78pt x 578
<diagram/benchmarks-group/bargraph-large-dtlb-walk.png, id=193, 1011.78pt x 578
.16pt>
File: diagram/benchmarks-group/bargraph-large-dtlb-walk.png Graphic file (type
png)
@@ -1585,7 +1573,7 @@ png)
Package pdftex.def Info: diagram/benchmarks-group/bargraph-large-dtlb-walk.png
used on input line 1050.
(pdftex.def) Requested size: 241.14749pt x 137.79964pt.
<diagram/benchmarks-group/bargraph-large-l1tlb-reads.png, id=209, 1011.78pt x 5
<diagram/benchmarks-group/bargraph-large-l1tlb-reads.png, id=194, 1011.78pt x 5
78.16pt>
File: diagram/benchmarks-group/bargraph-large-l1tlb-reads.png Graphic file (typ
e png)
@@ -1593,7 +1581,7 @@ e png)
Package pdftex.def Info: diagram/benchmarks-group/bargraph-large-l1tlb-reads.pn
g used on input line 1055.
(pdftex.def) Requested size: 241.14749pt x 137.79964pt.
<diagram/benchmarks-group/bargraph-large-l1tlb-refill.png, id=210, 1011.78pt x
<diagram/benchmarks-group/bargraph-large-l1tlb-refill.png, id=195, 1011.78pt x
578.16pt>
File: diagram/benchmarks-group/bargraph-large-l1tlb-refill.png Graphic file (ty
pe png)
@@ -1601,7 +1589,7 @@ pe png)
Package pdftex.def Info: diagram/benchmarks-group/bargraph-large-l1tlb-refill.p
ng used on input line 1063.
(pdftex.def) Requested size: 241.14749pt x 137.79964pt.
<diagram/benchmarks-group/bargraph-large-l2tlb-reads.png, id=211, 1011.78pt x 5
<diagram/benchmarks-group/bargraph-large-l2tlb-reads.png, id=196, 1011.78pt x 5
78.16pt>
File: diagram/benchmarks-group/bargraph-large-l2tlb-reads.png Graphic file (typ
e png)
@@ -1609,7 +1597,7 @@ e png)
Package pdftex.def Info: diagram/benchmarks-group/bargraph-large-l2tlb-reads.pn
g used on input line 1068.
(pdftex.def) Requested size: 241.14749pt x 137.79964pt.
<diagram/benchmarks-group/bargraph-large-ll-cache-rd.png, id=212, 1011.78pt x 5
<diagram/benchmarks-group/bargraph-large-ll-cache-rd.png, id=197, 1011.78pt x 5
78.16pt>
File: diagram/benchmarks-group/bargraph-large-ll-cache-rd.png Graphic file (typ
e png)
@@ -1617,7 +1605,7 @@ e png)
Package pdftex.def Info: diagram/benchmarks-group/bargraph-large-ll-cache-rd.pn
g used on input line 1076.
(pdftex.def) Requested size: 241.14749pt x 137.79964pt.
<diagram/benchmarks-group/bargraph-large-wallclock.png, id=213, 1011.78pt x 578
<diagram/benchmarks-group/bargraph-large-wallclock.png, id=198, 1011.78pt x 578
.16pt>
File: diagram/benchmarks-group/bargraph-large-wallclock.png Graphic file (type
png)
@@ -1626,13 +1614,11 @@ Package pdftex.def Info: diagram/benchmarks-group/bargraph-large-wallclock.png
used on input line 1081.
(pdftex.def) Requested size: 241.14749pt x 137.79964pt.
Class acmart Warning: A possible image without description on input line 1089.
Underfull \vbox (badness 10000) has occurred while \output is active []
[5.5]
Underfull \vbox (badness 10000) has occurred while \output is active []
@@ -1645,12 +1631,6 @@ Underfull \vbox (badness 10000) has occurred while \output is active []
Overfull \hbox (1.64574pt too wide) in paragraph at lines 1126--1134
[]\T1/LinuxLibertineT-TLF/m/n/9 (-20) DTLB walks: Data Trans-la-tion Looka-side
Buffer (dTLB) walks,
[]
Underfull \vbox (badness 10000) has occurred while \output is active []
@@ -1660,15 +1640,13 @@ marks-group/bargraph-large-l1tlb-reads.png> <./diagram/benchmarks-group/bargrap
h-large-l1tlb-refill.png> <./diagram/benchmarks-group/bargraph-large-l2tlb-read
s.png> <./diagram/benchmarks-group/bargraph-large-ll-cache-rd.png> <./diagram/b
enchmarks-group/bargraph-large-wallclock.png>]
Underfull \vbox (badness 10000) has occurred while \output is active []
[8.8] (./paper.bbl
(./paper.bbl
[8.8]
Underfull \hbox (badness 2443) in paragraph at lines 141--145
[]\T1/LinuxLibertineT-TLF/m/n/7 (+20) CHERI-allocator/benchmarks/benchmarks/Str
essTestMalloc/glibc-bench.c at
@@ -1687,8 +1665,10 @@ Class acmart Warning: CCS concepts are mandatory for papers over two pages.
Package balance Warning: You have called \balance in second column
(balance) Columns might not be balanced.
Overfull \vbox (1.152pt too high) has occurred while \output is active []
(/usr/local/texlive/2025/texmf-dist/tex/generic/stringenc/se-pdfdoc.def
File: se-pdfdoc.def 2019/11/29 v1.12 stringenc: PDFDocEncoding
@@ -1709,13 +1689,13 @@ Package rerunfilecheck Info: File `paper.out' has not changed.
(rerunfilecheck) Checksum: DFB5CD2E0B64721769D9BBB90A3777D7;3482.
)
Here is how much of TeX's memory you used:
26504 strings out of 473190
451278 string characters out of 5715801
1049088 words of memory out of 5000000
48526 multiletter control sequences out of 15000+600000
779187 words of font info for 476 fonts, out of 8000000 for 9000
26499 strings out of 473190
451169 string characters out of 5715801
1043466 words of memory out of 5000000
48524 multiletter control sequences out of 15000+600000
778914 words of font info for 474 fonts, out of 8000000 for 9000
1302 hyphenation exceptions out of 8191
94i,17n,131p,1002b,780s stack positions out of 10000i,1000n,20000p,200000b,200000s
94i,17n,131p,1002b,797s stack positions out of 10000i,1000n,20000p,200000b,200000s
</usr/local/texlive/2025/texmf-dist/fonts/type1/public/inconsolata/Inconsolat
a-zi4r.pfb></usr/local/texlive/2025/texmf-dist/fonts/type1/public/newtx/Liberti
neMathMI.pfb></usr/local/texlive/2025/texmf-dist/fonts/type1/public/libertine/L
@@ -1728,7 +1708,7 @@ lic/libertine/LinLibertineTB.pfb></usr/local/texlive/2025/texmf-dist/fonts/type
/type1/public/newtx/NewTXMI.pfb></usr/local/texlive/2025/texmf-dist/fonts/type1
/public/newtx/txmiaX.pfb></usr/local/texlive/2025/texmf-dist/fonts/type1/public
/newtx/txsys.pfb>
Output written on paper.pdf (9 pages, 824270 bytes).
Output written on paper.pdf (9 pages, 820640 bytes).
PDF statistics:
339 PDF objects out of 1000 (max. 8388607)
283 compressed objects within 3 object streams

BIN
docs/EuroSys/Paper/paper.pdf
View File

Binary file not shown.

104
docs/EuroSys/Paper/paper.tex
View File

@@ -568,12 +568,12 @@ FAT memory ranges are established using
bounds encoded within the pointer, adhering to CHERI CC~\cite{woodruff_cheri_2019}.
% 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.
% 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}
@@ -662,12 +662,12 @@ memory patterns within physically contiguous memory.
%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.
% 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}
@@ -1104,28 +1104,37 @@ patterns benefit from its design. The results align with expectations, showcasin
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: 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: L1 DTLB 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 23\% fewer L1 DTLB reads than the baseline allocator.
However, when the FAT allocator was embedded within Jemalloc, the L1 DTLB reads were the same as the baseline.
For the memaccess benchmark, the embedded FAT allocator resulted in 72\% fewer L1 DTLB reads compared to the baseline
allocator. A similar pattern was observed with Glibc, showing 62\% fewer L1 DTLB reads. In the Richards benchmark,
there was no discernible difference for either allocator. For the Barnes benchmark, the FAT allocator exhibited 5\%
fewer L1 DTLB reads, and the result was the same for the FAT allocator embedded within Jemalloc.
\item L2 DTLB reads: L2 Data TLB reads (or lookups) serve as a secondary cache for address translations, and, similar to L1 TLB, lower values are
indicative of better performance. FAT allocator consistently performed at the baseline (100\%) for this metric across all benchmarks.
indicative of better performance. FAT allocator consistently performed at the baseline (100\%) for this metric across all benchmarks except Barnes.
FAT allocator embedded inside Jemalloc also showed no significant change for Kmeans, Memaccess, and Richards. However, for the Glibc benchmark,
it achieved a significant reduction of 60\% in L2D TLB reads. 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. A minor reduction of 3\% was also observed for the Barnes
benchmark with FAT allocator embedded inside Jemalloc.
\item DTLB walks: Data Translation Lookaside Buffer (dTLB) walks, which occur when a virtual-to-physical
\item DTLB walks: 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
cost. thus, fewer walks are preferable. In the observed tests neither FAT allocator nor FAT allocator embedded inside Jemalloc
demonstrated any significant deviation from the baseline performance (100\%) for this metric.
This consistent behavior was noted across all benchmarks evaluated: Kmeans, Memaccess, Glibc, Richards, and Barnes.
This outcome suggests that the memory allocation strategies employed by these allocators do not substantially alter the frequency
@@ -1137,30 +1146,31 @@ of its capability to handle memory more efficiently by leveraging huge pages.
remained at the baseline (100\%) 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. This outcome presents a point of potential inconsistency;
if L1D TLB reads (interpreted as events related to misses or lookups that could lead to misses) are reduced, a corresponding decrease in actual
refills would typically be expected. 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.
refills would typically be expected.
% 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: Last-Level Cache (LLC) 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 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 Last-level cache: 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 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: Wallclock time provides the ultimate measure of overall execution performance, 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.
% \item Wall clock: Wallclock time provides the ultimate measure of overall execution performance, 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}
A particularly striking observation is the significant reduction in data TLB walks,