diff options
author | Bent Bisballe Nyeng <deva@aasimon.org> | 2023-08-06 21:03:23 +0200 |
---|---|---|
committer | Bent Bisballe Nyeng <deva@aasimon.org> | 2023-08-06 21:03:23 +0200 |
commit | 1dc5f04a930abde1f21d83ab066c32f4a2d105cb (patch) | |
tree | d3c1b8804db3fa1aedca5f44d0e2ded3508ccba0 /a6 | |
parent | 5e9ffc26c26cbcb85a9e18f719fde1b9c178477f (diff) |
A6: WIP
Diffstat (limited to 'a6')
-rw-r--r-- | a6/au_BentBisballeNyeng_A6.tex | 51 |
1 files changed, 27 insertions, 24 deletions
diff --git a/a6/au_BentBisballeNyeng_A6.tex b/a6/au_BentBisballeNyeng_A6.tex index 107e62a..6acd180 100644 --- a/a6/au_BentBisballeNyeng_A6.tex +++ b/a6/au_BentBisballeNyeng_A6.tex @@ -40,7 +40,7 @@ allocations (such as smart-pointers), but can still be used for managing other types of resources, such as locks or hardware peripheral access. -\subsection{Dynamic Memory Allocation} +\subsection{Dynamic Memory Allocation}\label{dyn} There can be many reasons for not allocating on the free-store, either by convention; ``no allocations allowed after the engines has @@ -52,7 +52,7 @@ memory depletion\cite{weis}. In the case of memory fragmentation one might argue that it is not the allocation that is the problem but rather the free'ing since this is -when the fragmentation happens. This problem is shown in +when the fragmentation happens. The problem is shown in figure \ref{frag}, which might be possible to circumvent in singular concrete cases, but cannot be solved in general without the page indirections of the virtual memory\cite{weis}. @@ -69,17 +69,19 @@ fragmentation.}} \label{frag} \end{figure} -This can to some degree be prevented by monotonic allocations which -might work for not very practical in real-world -software and certainly not for the dynamic allocations in the STL or -the core-language. +This can to some degree be prevented by monotonic allocations where +each allocation always has the same size and therefore can be re-used +directly after being freed. This might work for some special usecases, +where objects of similar size are being stored in a pool may not be +applicable in software in general and certainly not for the dynamic +allocations in the STL or the core-language. In particular, a lambda stored in a \texttt{std::function} might -allocate memory on the free-store if the lambda exceeds the size of -the (compiler dependent) small-buffer optimization (SBO) buffer inside -the \texttt{std::functions}\cite{elbeno}. In much the same way as -the \texttt{std::string} has its small string optimization (also -compiler dependent). +allocate memory on the free-store if the lambda captures exceeds the +size of the (compiler dependent) small-buffer optimization (SBO) +buffer inside the \texttt{std::functions}\cite{elbeno}. In much the +same way as the \texttt{std::string} has its small string optimization +(SSO) which are also compiler dependent in size. \subsection{Free-Standing} @@ -142,18 +144,18 @@ There exists a \texttt{-ffreestanding} argument, but this follows the old (current) definition of free-standing and as such allows dynamic allocation so it cannot be used. -Some constructs have built-in optimizations that make them store their -data in local members, instead of on the free-store through a pointer, -until som limit is reached making it possible to use for -example \texttt{std::string}s or \texttt{std::function}s as long as -they don't require more than $N$ bytes, where $N$ is a compiler -dependent. +As mentiond in section \ref{dyn}, some constructs have built-in +optimizations that make them store their data in local members, +instead of on the free-store through a pointer, until som limit is +reached making it possible to use for example \texttt{std::string}s +or \texttt{std::function}s as long as they don't require more than $N$ +bytes, where $N$ is a compiler dependent. -To detect if a free-store allocation is done a simple overload +To detect if or when a free-store allocation is done a simple overload of \texttt{new} is made, which simply throws an exeption if called. -This will lead to a run-time error and not a compile-time one as would -have been the ideal solution, but at least it can assists in finding -the $N$ for a specific compiler. +This will lead to a run-time error and not a compile-time one, which +would otherwise have been the ideal solution, but at least it can +assists in finding the $N$s for a specific compiler. The code could simply look something like this: @@ -164,11 +166,12 @@ void* operator new(std::size_t) } \end{lstlisting}\normalsize -The code for this experiment can be found in the \texttt{noalloc.cc} -file. +The complete code for this experiment can be found in +the \texttt{noalloc.cc} file. The following table shows the impirically deduced sizes of $N$ wherever SSO or SBO is available along with comments about the general component -behaviour.\\ +behaviour. The sizes were simply increased until the compiled program +started throwing the \texttt{std::bad\_alloc} exception.\\ \noindent\begin{tabular}{| l | c | l |} \hline |