Modern computers are designed to store and retrieve data during application runtimes. Every modern device or computer is designed to allow one or more applications to run while reading and writing supporting data. Data can be stored either long-term or short-term. For long-term storage, we use storage media such as hard disks. This is what we call non-volatile storage. If the device loses power, the data remains and can be reused later, but this type of storage is not optimized for high-speed situations.

Outside of data needed for extended periods, applications must also store data between processes. Data is constantly being written, read, and removed as an application performs various operations. This data type is best stored in volatile storage or memory caches and arrays. In this situation, the data is lost when the device loses power, but data is read and written at a very high speed while in use.

One practical example where it’s better to use volatile memory instead of non-volatile memory for performance reasons is cache memory in computer systems. Cache memory is a small, fast type of volatile memory that stores frequently accessed data and instructions to speed up processing. It’s typically faster than accessing data from non-volatile memory, such as hard disk drives (HDDs) or solid-state drives (SSDs). When a processor needs to access data, it first checks the cache memory. If the data is in the cache (cache hit), the processor can retrieve it quickly, resulting in faster overall performance. However, if the data is not in the cache (cache miss), the processor needs to access it from slower, non-volatile memory, causing a delay in processing.

In this scenario, using volatile memory (cache memory) instead of non-volatile memory (HDDs or SSDs) improves performance because volatile memory offers much faster access times. This is especially critical in systems where latency is a concern, such as high-performance computing, gaming, and real-time processing applications. Overall, leveraging volatile memory helps reduce the time it takes to access frequently used data, enhancing system performance and responsiveness.

Memory is a general name given to an array of rapidly available information shared by the CPU and connected devices. Programs and information use up this memory while the processor carries out operations. The processor moves instructions and information in and out of the processor very quickly. This is why caches (at the CPU level) and Random Access Memory (RAM) are the storage locations immediately used during processes. CPUs have three cache levels: L1, L2, and L3. L1 is the fastest, but it has low storage capacity, and with each higher level, there is more space at the expense of speed. They are closest to the CPU for temporary storage and high-speed access. Figure 1.1 depicts the layout of the different cache levels.

Figure 1.1 – The different cache levels in a CPU and per CPU core

Each processor core contains space for L1 and L2 caches, which allow each core to complete small tasks as quickly as possible. For less frequent tasks that might be shared across cores, the L3 cache is used and is shared between the cores of the CPU.

Memory management, in principle, is a broad-brush expression that refers to techniques used to optimize a CPU’s efficient usage of memory during its processes. Consider that every device has specifications that outline the CPU speed and, more relevantly, storage and memory size. The amount of memory available will directly impact the types of applications that can be supported by the device and how efficiently the applications will perform on such a device. Memory management techniques exist to assist us, as developers, in ensuring that our application makes the best use of available resources and that the device will run as smoothly as possible while using the set amount of memory to handle multiple operations and processes.

Memory management considers several factors, such as the following:

• The capacity of the memory device: The less memory that is generally available, the more efficient memory allocation is needed. In any case, efficiency is the most critical management factor, and failing here will lead to sluggish device performance.
• Recovering memory space as needed: Releasing memory after processes run is essential. Some processes are long-running and require memory for extended periods, but shorter-running ones use memory temporarily. Data will linger if memory is not reclaimed, creating unusable memory blocks for future processes.
• Extending memory space through virtual memory: Devices generally have volatile (memory) and non-volatile (hard disk) storage. When volatile memory is at risk of maxing out, the hard disk facilitates additional memory blocks. This additional memory block is called a swap or page file. When the physical memory becomes full, the OS can transfer less frequently used data from RAM to the swap file to free up space for more actively used data.

Devices with CPUs generally have an OS that coordinates resource distribution during processes. This resource distribution is relative to the available hardware, and the performance of the applications is relative to how efficiently memory is managed for them.

A typical has three major areas where memory management is paramount to the performance of said device. These three areas are hardware, application, and the OS. Let’s review some of the nuances that govern memory management at these levels.

Levels of memory management

There are three levels where memory management is implemented, and they are as follows:

• Hardware: RAM and central processing unit (CPU) caches are the hardware components that are primarily involved in memory management activities. RAM is physical memory. This component is independent of the CPU, and while it is used for temporary storage, it boasts much more capacity than the caches and is considerably slower. It generally stores larger and less temporary data, like data needed by long-running applications.
• The memory management unit (MMU), a specialized hardware component that tracks logical or virtual memory and physical address mappings, manages the usage of both RAM and CPU caches. Its primary functions include allocation, deallocation, and memory space protection for various processes running concurrently on the system. Figure 1.2 shows a high-level representation of the MMU and how it maps to the CPU and memory in the system.

Figure 1.2 – The CPU and MMU and how they connect to memory spaces in RAM

• OS: Systems with CPUs tend to have a system that orchestrates processes and operations at a root level. This is called an operating system (OS). An OS ensures that processes are started and stopped successfully and orchestrates how memory is distributed across the different memory stores for many processes. It also tracks the memory blocks to ensure it knows which resources are being used and by what process to reclaim memory as needed for the following process. OSs also employ several memory allocation methods to ensure the system runs optimally. If physical memory runs out, the OS will use virtual memory, a pre-allocated space on the device’s storage medium. Storage space is considerably slower than RAM, but it helps the OS to ensure that the system resources are used as much as possible to prevent system crashes.
• Application: Different applications have their memory requirements. Developers can write memory allocation logic to ensure that the application controls memory allocation and not the other systems, such as the MMU or the OS. Two methods are generally used by applications to manage their memory allocation are:
  • Allocation: Memory is allocated to program components upon request and is locked exclusively for use by that component until it is no longer needed. A developer can manually and explicitly program allocation logic or automatically allow the memory manager to handle allocation using the allocator component. The memory manager option is usually included in a programming language/runtime. If it isn’t, then manual allocation is required.
  • Recycling: This is handled through a process called garbage collection. We will look at this concept in more detail later, but in a nutshell, this process will reclaim previously allocated and no-longer-in-use memory blocks. This is essential to ensure that memory is either in use or waiting to be used, but not lost in between. Some languages and runtimes automate this process; otherwise, a developer must provide logic manually.

  Application memory managers have several hurdles to contend with. It must be considered that memory management requires the CPU, which will cause competition for the system resources between this and other processes. Also, each time memory allocation or reclamation happens, there is a pause in the application as focus is given to that operation. The faster this can happen, the less obvious it is to the end user, so it must be handled as efficiently as possible. Finally, the more memory is allocated and used, the more fragmented the memory becomes. Memory spreads across non-contiguous blocks, leading to higher allocation times and slower read speeds during runtime.

Figure 1.3 – A high-level representation of a computer’s memory hierarchy

Each component in a computer’s hardware and OS has a critical role to play in how memory is managed for applications. If we are to ensure that our devices perform at their peak, we need to understand how resource allocation occurs and some of the potential dangers that poor resource management and allocation can lead to. We will review these topics next.

Memory management is a sufficiently challenging technique to incorporate in application development. One of the top challenges is knowing when to retain or discard data. While the concept sounds easy, the fact that it is an entire field of study speaks volumes. Ideally, programmers wouldn’t need to worry about the details in between, but knowing different techniques and how they can be used to ensure maximum efficiency is essential.

Contiguous allocation is the oldest and most straightforward allocation method. When a process is about to execute, and memory is requested, the required memory is compared to the available memory. If sufficient contiguous memory can be found, then allocation occurs, and the process can execute successfully. If an adequate amount of memory contiguous memory blocks cannot be found, then the process will remain in limbo until sufficient memory can be found.

Figure 1.4 shows how memory blocks are aligned and how the assignment is attempted in contiguous allocation. Conceptually, memory blocks are sequentially laid out, and when allocation is required, it is best to place the data being allocated in blocks beside each other or contiguously. This makes read/write operations in applications that rely on the allocated data more efficient.

Figure 1.4 – How contiguous allocation works

The preference for contiguously allocated blocks is evident when we consider that contiguous memory blocks are more accessible to read and manipulate than non-contiguous blocks. One drawback, however, is that memory might not be used effectively since the entire allocation must be successful, or the allocation will fail. For this reason, memory might not get allocated to smaller contiguous blocks.

As developers, we can use the following tips as guidelines to ensure that contiguous allocation occurs in our applications:

• Static allocation – We can ensure that we use variables and data structures where a fixed size is known and allocated at application runtime. For instance, arrays are allocated contiguously in memory.
• Dynamic allocation – We can manually manage memory blocks of fixed sizes. Some languages, such as C and C++, allow you to allocate memory on the fly using functions such as malloc() and calloc(). Similarly, you can prevent fragmentation by deallocating memory when it is no longer in use. This ensures that memory is being used and freed as efficiently as possible.
• Memory pooling – You can reserve a fixed memory space when the application starts. This fixed space in memory will be used exclusively by the application for any resource requirements during the runtime of the application. The allocation and deallocation of memory blocks will also be handled manually, as seen previously.

These techniques can help developers write applications that ensure contiguous memory allocation as and when necessary for certain systems and performance-critical applications.

With contiguous memory, we have the options of stack and heap allocation. Stack allocation pre-arranges the memory allocation and implements it during compilation, while heap allocation is done during runtime. Stack allocation is more commonly used for contiguous allocation, and this is a perfect match since allocation happens in predetermined blocks. Heap allocation is a bit more difficult since the system must find enough memory, which might not be possible. For this reason, heap allocation suits non-contiguous allocation.

Non-contiguous allocation, in contrast to contiguous allocation, allows memory to be allocated across several memory blocks that might not be beside each other. This means that if two blocks are needed for allocation and are not beside each other, then allocation will still be successful.

Figure 1.5 displays memory blocks to be assigned to a process, but the available slots are at opposite ends of the contiguous block. In this model, the process will still receive its allocation request, and the memory blocks will be used efficiently as the empty spaces are used as needed.

Figure 1.5 – How non-contiguous allocation works, where empty memory blocks are used even when they are separated

This method, of course, comes at the expense of optimal read/write performance, but it does help an application move forward with its processes since it might not need to wait too long before memory can be found to fulfill its requests. This also leads to a common problem called fragmentation, which we will review later.

Even with the techniques and recommendations, there are many scenarios where a poor implementation of memory management can affect the robustness and speed of programs. Typical problems include the following:

• Premature frees: When a program gives up memory but attempts to access it later, causing a crash or unexpected behavior.
• Dangling pointers: When a program ends but leaves a dangling reference to the memory block it was allocated.
• Memory leak: When a program continually allocates and never releases memory. This will lead to memory exhaustion on the device.
• Fragmentation: Fragmentation is when a solid gets split into many pieces. Programs operate best when memory is allocated linearly. When memory is allocated using too many small blocks, it leads to poor and inadequate distribution. Eventually, despite having enough spare memory, it can no longer give out big enough leagues.
• Poor locality of reference: Programs operate best when successive memory accesses are nearer to each other. Like the fragmentation problem, if the memory manager places the blocks a program will use far apart, this will cause performance problems.

As we have seen, memory must be handled delicately and has limitations we must be aware of. One of the most significant limitations is the amount of space available to an application. In the next section, we review how memory space is measured.

Units of memory storage

It is essential to know the different units of measurement and overall sizes that specific keywords represent in memory management. This will give us a good foundation for discussing memory and memory usage.

• Bit: The smallest unit of information. A bit can have one of two possible numerical values (1 and 0), representing logical values (true and false). Multiple bits combine to form a binary number.
• Binary number: A numerical (usually an integer) value formed from a sequence of bits, or ones and zeros. Each bit in the sequence represents a value to the power of 2, with each 1 contributing to the sum of the given value. To convert a binary number to decimal, multiply each digit from left to right by the power of 2. The rightmost digit gets the lowest power.

  For example, the binary number 1101 represents 1 * 8 + 1 * 4 + 0 * 2 + 1 * 1 to give a total of 13. Figure 1.6 shows a simple table with the binary positions relative to the power of 2.

Figure 1.6 – A simple binary table with example values

• Binary code: Binary sequences representing alphanumerical and special characters. Each bit sequence is assigned to specific data. The most popular code is ASCII code, which uses 7-bit binary code to represent text, numbers, and other characters.
• Byte: A byte is a sequence of 8 bits that encodes a single character using specified binary code. Since bit and byte begin with the letter b, an uppercase B is used to depict this data size. It also serves as the base unit of measurement, where increments are usually in the thousands (Kilo = 1000, Mega = 1,000,000, etc.)

Now that we understand memory management and its importance, let’s look closely at memory and how it works to ensure that our applications run smoothly.

The fundamentals of how memory works

When considering how applications work and how memory is used and allocated, it is good to have at least a high-level understanding of how computers see memory, the states that memory can exist in, and how algorithms decide how to allocate it.

For starters, each process has its own virtual address space but will share the same physical memory. When developing applications, you will work only with the virtual address space, and the garbage collector allocates and frees virtual memory for you on the managed heap. At the OS level, you can use native functions to interact with the virtual address space to allocate and free virtual memory for you on native heaps.

Virtual memory can be in one of three states:

• Reserved: The memory block is available for your use and can’t be accessed until it’s committed
• Free: The memory block has no references and is available for allocation
• Committed: The block of memory is assigned to physical storage

Memory can become fragmented as memory gets allocated and more processes are spooled up. This means that, as mentioned earlier, the memory is split across several memory blocks that are not contiguous. This leads to holes in the address space. The more fragmented memory becomes, the more difficult it becomes for the virtual memory manager to find a single free block large enough to satisfy the allocation request. Even if you need a space of a specific size and have that amount of space available cumulatively, the allocation attempt might fail if it cannot happen over a single address block. Generally, you will run into a memory exception (like an OutOfMemoryException in C#) if there isn’t enough virtual address space to reserve or physical space to commit. See Figure 1.5 for a visual example of how fragmentation might look. The process that has been allocated memory has to check in two non-contiguous slots for relevant information. There is a free space in memory during the process runtime, but it cannot be used until another process requests it. This is an example of fragmented memory.

We need to be careful when allocating memory in terms of ordering the blocks to be allocated relative to each new object or process. This can be a tedious task, but thankfully, the .NET runtime provides mechanisms to handle this for us. Let’s review how .NET handles memory allocation for us.

Automatic memory allocation in .NET

Each OS boasts unique and contextually efficient memory allocation techniques. The OS ultimately governs how memory and other resources are allocated to each new process to ensure efficient resource utilization relative to the hardware and available resources.

When writing applications using the .NET runtime, we rely on its ability to allocate resources automatically. Because .NET allows you to write in several languages (C#, C++, Python, etc.), it provides a common language runtime (CLR) that compiles the original language(s) into a single runtime language called managed code, which is executed in a manager execution environment.

With managed code, we benefit from cross-language integration and enhanced security, versioning, and deployment support. We can, for example, write a class in one language and then use a different language to derive a native class from the original class. You can also pass objects of that class between the languages. This is possible given that the runtime defines rules for creating, using, persisting, and binding different reference types.

The CLR gives us the benefit of automatic memory management during managed execution. You do not need to write code to perform memory management tasks as a developer. This eliminates most, if not all, of the negative allocation scenarios that we previously explored. The runtime reserves a contiguous region of address space for each initialized new process. This reserved address space is the managed heap, which is initially set to the base address of the managed heap.

All reference types, as defined by the CLR, are allocated on the managed heap. When the application creates its first reference type instance, memory is allocated at the managed heap’s base address. For every initialized object, memory is allocated in the contiguous memory space following the previously allocated space. This allocation method will continue with each new object, if address space is available.

This process is faster than unmanaged memory allocation since the runtime handles the memory allocation through pointers, which makes it almost as fast as allocating memory directly from the CPU’s stack. Because new objects allocated consecutively are stored contiguously in the managed heap, an application can access the objects quickly.

The allocated memory space must continuously be reclaimed to ensure an effective and efficient operation. You can rely on a built-in mechanism called a garbage collector to orchestrate this process, and we will discuss this at a high level next.

Garbage collection is the process that governs how programs release memory space that is no longer being used for their operations. This process serves as an automatic memory manager by managing the allocation and release of memory for an application.

Programming languages that support automatic garbage collection free developers from the need to write specific code to perform memory management tasks. Languages that implement automatic memory management allow us to build applications without accounting for common problems such as memory leaks or an application attempting to access freed memory for an already freed object.

Each language handles garbage collection differently, and it is crucial to appreciate how it works in your context. As mentioned, the CLR in .NET implements it automatically, but additional libraries may be required in low-level programming languages such as C. For instance, C developers must handle allocation and deallocation using the malloc() and dealloc() functions. In contrast, it is not recommended for a C# developer to handle this as it is already taken care of.

Recall that in C#, allocation happens through a managed heap, and objects are placed in contiguous spaces in memory. In contrast, in C, objects are placed where there is free memory, and locations are tracked through a linked list. Memory allocation will work faster in CLR-supported languages since the allocation is done linearly, ensuring a contiguous allocation process. In C, memory must be traversed to find the next available slot, adding additional time to the allocation process. We will review the details of the allocation process of the CLR in the next chapter.

Here are some additional benefits of the garbage collector:

• Allocates objects on the managed heap efficiently
• Reclaims memory from objects no longer being used so that memory is available for future allocations
• Provides memory safety by ensuring an object can’t claim memory allocated for another object

The garbage collector boasts an optimized engine that performs collection operations at the best possible time based on static fields, local variables on a thread’s stack, CPU registers, GC handles, and the finalized queue from the application’s roots. Each root should refer to an object on the managed heap or have a null value. The garbage collector can ask the rest of the runtime for these roots and will use this list to create a graph containing all the objects accessible from the roots. Any unreachable object is classified as garbage, and the memory that it is using is released.

Garbage collection happens under one of these situations:

• The operating system or host has notified that there is low memory.
• Memory being used by the allocated objects on the managed heap exceeds an acceptable threshold.
• The developer called the GC.Collect() function, which forces a collection event. This is not generally required since the GC operates automatically.

The managed heap the GC uses to manage allocation is divided into three sections called generations. Let’s take a closer look at how these generations work and the pros and cons of this mechanism.

Garbage collection in .NET

The GC in .NET has three generations labeled 0, 1, and 2. Each generation is dedicated to tracking objects based on their expected lifetime. Generation 0 stores short-lived objects, ranging to Generation 2 for more long-term objects.

• Generation 0: This generation stores short-lived objects such as temporary variables. When this generation is full and new objects are to be created, the GC will free up space by examining the objects in generation 0 rather than all objects in the managed heap.
• Generation 1: This generation sits between generations 0 and 2. After a GC event in generation 0, objects are compacted and promoted to this generation, where they will enjoy a longer lifetime. When a GC operation is run on this generation, objects that survive get promoted to Generation 2.
• Generation 2: Long-lived objects such as static data and singleton objects are stored in this generation. Anything that survives a collection event on this level stays until it becomes unreachable in a future collection. Collections at this level are also called full garbage collections since they reclaim all generations in the heap.

The garbage collector has an additional heap for large objects, called the Large Object Heap (LOH). This heap is used for objects that are 85,000 bytes or more. Collection events on the LOH and Generation 2 generally take a long time, given the size and lifetime of the cleaned objects.

Garbage collection starts with a marking phase, where it finds and creates a list of all currently allocated objects. It then enters a relocating phase, where references related to the surviving objects are updated. Then, there is a compacting phase where space is reclaimed from dead objects, and the surviving objects are compacted. Compaction is simply the process of moving memory blocks beside each other, which, as mentioned before, is a significant factor in the CLR’s efficient memory allocation method.

Applications consist of several processes and processes run on threads. A thread is a basic to which the OS allocates processor time. The .NET runtime and CLR manage threads, and when a garbage collection operation begins, all managed threads are suspended except for the thread that triggered the collection event.

It is generally ill-advised to run the GC.Collect() method manually for several reasons. This method will pause your application and allow the collector to run. This may cause your application to become unresponsive and degrade its performance. In addition, the process is not guaranteed to free all unused objects from memory, and those still in use by your application will not be collected. This method should only be used when the application no longer uses any objects that the collector previously collected.

The drawback of garbage collection lies in its effect on performance. Garbage collection must periodically traverse the program, inspecting object references and reclaiming memory. This process consumes system resources and frequently necessitates program pauses.

It is easy to see why garbage collection is a fantastic tool that spares us from carrying out manual memory management and space reclamation. Now, let’s review some of memory management’s impacts on overall application performance.

We have seen the importance of proper and efficient memory management in our applications. Fortunately, .NET makes it easier for us developers by implementing automatic garbage collection to clean up objects in between processes.

Memory management operations can significantly affect your application’s performance as allocation and deallocation activities require system resources and might compete with other processes in progress. Take, for example, the garbage collection process, which pauses threads while it traverses the different generations to collect and dispose of old objects.

Now, let’s itemize and review some of our application’s benefits and the potential pitfalls of memory management:

• Responsiveness: Efficient memory management can significantly improve the responsiveness of your application. Your program can run smoothly without unexpected slowdowns or pauses when memory is allocated and deallocated judiciously.
• Speed: Memory access times are critical for application speed. Well-organized memory management can lead to more cache-friendly data structures and fewer cache misses, resulting in faster execution times.
• Stability: Memory leaks and memory corruption are common issues in applications with suboptimal memory management. Memory leaks occur when memory is allocated but never released, leading to a gradual consumption of resources and potential crashes.
• Scalability: Applications that manage memory efficiently are more scalable. They can handle large datasets and user loads without running into memory exhaustion issues.
• Resource Utilization: Efficient memory management minimizes memory wastage, allowing your application to run on systems with lower hardware specifications. This can widen your application’s potential user base and reduce infrastructure costs.

We can expect these tangible benefits when an application appropriately manages memory. Similarly, there can be some adverse effects when the correct measures are not taken.

Impacts of poor memory management

Memory management can significantly negatively impact application performance if not handled properly. Here are some ways in which poor memory management can adversely affect your application’s performance:

• Memory leaks: Memory leaks occur when an application fails to release any longer-needed memory. Over time, these leaked memory blocks accumulate, consuming more and more memory resources. This can lead to excessive memory usage, reduced available system memory, and, eventually, application crashes or slowdowns.
• Inefficient memory usage: Inefficient memory allocation and deallocation strategies can lead to higher memory consumption than necessary. This can result in your application using more memory than it needs, which can slow down the entire system and reduce the responsiveness of your application.
• Fragmentation: Memory fragmentation occurs when memory is allocated and deallocated in a way that leaves small, unusable gaps of memory scattered throughout the heap. This fragmentation can lead to inefficient memory usage, challenging allocating contiguous memory blocks for more extensive data structures or objects. This can cause slower memory access times and reduced application performance.
• Cache thrashing: Cache memory is much faster to access than main system memory. Poor memory management can lead to the CPU cache frequently being invalidated and reloaded with data from the main memory due to inefficient memory access patterns. This can result in significant performance degradation.
• Increased paging and swapping: When an application consumes too much memory, the OS may resort to paging or swapping data between RAM and disk storage. This involves reading and writing data to and from slower disk storage, which can lead to a noticeable slowdown in application performance.
• Concurrency issues: In multi-threaded applications, improper memory management can lead to race conditions, data corruption, and other concurrency issues. Conflicting memory accesses by multiple threads can result in unexpected behavior and performance bottlenecks.
• Increased garbage collection overhead: In languages with automatic memory management, such as C#, inefficient memory management practices can lead to more frequent garbage collection cycles. These cycles pause the application briefly to clean up unreferenced objects, which can introduce noticeable delays and reduce overall performance.
• Resource contention: When an application consumes excessive memory, it can lead to resource contention with other running processes on the same system. This can result in competition for system resources (CPU, memory, I/O), leading to degraded performance for all running applications.
• Poor scalability: Applications with inefficient memory management may struggle to scale. As user loads and data sizes increase, the application’s memory demands can become a limiting factor, preventing it from handling larger workloads effectively.

When scoping our applications, we must consider the context that the application is for, the device it will run on, and the resources that will be available. This may lead us to choose a particular language or development stack. Let’s review some key considerations.

Key considerations

To ensure optimal performance, developers should carefully consider memory management practices and employ appropriate techniques and tools to mitigate these issues.

It is also important to note that one size does not fit all. When considering the memory management technique that will be implemented, as developers, we must consider the following:

• The type of operations being supported and if they will perform optimally based on how memory is allocated and managed
• The target devices and expected system resources, since a mobile device allocation will differ from a computer’s allocation
• The target OS, since each will implement its overall management methods

Now that we understand memory management, techniques, and factors, let’s review what we have learned.

This chapter explored the fundamental concepts of memory management in computer systems. Memory management is critical for OSs efficiently utilizing a computer’s memory resources.

We discussed memory hierarchy, which consists of various levels of memory, from registers and cache to RAM and storage devices. Understanding this hierarchy is essential for optimizing memory usage. We then reviewed how memory is allocated to different processes or programs running on a computer, allocation strategies, and their implications on system performance.

We also reviewed a popular memory management technique in garbage collection and how it works in .NET. Garbage collection automatically identifies and frees up unused objects or data memory and excuses the developer from writing manual memory management logic. This behavior also reduces memory overhead and improves overall application performance.

This chapter provided a comprehensive overview of memory management in computer systems, emphasizing its importance in ensuring efficient resource utilization, process isolation, and system reliability. It sets the foundation for understanding the intricacies of memory management in modern OSs.

Next, we look at garbage collection in more depth and see how objects are handled.