---
title: "Garbage Collector"
id: lexicon/G/Garbage Collector
canonical: /lexicon/G/Garbage Collector/
---

Garbage Collector (GC) is a mechanism used in some <<<CPLs>>> to help manage memory automatically.
In simple terms, it is a tool that cleans up memory when certain data is no longer needed, helping applications use resources efficiently.

Different CPLs use different memory management strategies, each with its own pros and cons. Three main approaches are:

- **Manual Management**: The developer is responsible for explicitly releasing resources when they are no longer needed.  
- **Automatic Management (GC)**: The runtime identifies and frees memory (the “garbage”) when it is no longer referenced.  
- **Ownership Model**: Memory is mostly freed automatically, with additional compile-time checks to ensure that data is valid whenever it is referenced.  

Each of these comes with trade-offs:

- **Manual Management**: Memory management is a low-level concern, and delegating it to developers often leads to bugs, leaks, and runtime exceptions.  
- **Automatic Management (GC)**: Requires extra processing at runtime and can introduce unpredictable pauses or performance behavior.  
- **Ownership Model**: Often provides strong guarantees, but at the cost of significant cognitive load on developers, which can harm the overall developer experience.  

Simorg takes a different approach. First, it does **not** use a GC model: designing a processing model that inherently generates “garbage” is considered wasteful and contrary to the principle of wisdom.
Second, as mentioned elsewhere, memory management is treated as a low-level concern that should not involve either human or non-human users directly.

As noted multiple times, Simorg’s processing model gives priority to Data rather than procedures. In other words, when we write Simorg Code, we are defining pathways for Data. When there is no longer any pathway for a piece of Data, it is removed from memory.

A natural question arises: how does this behavior align with Simorg’s physical model, where Data in transit is considered a form of Energy? Does removing Data from memory violate the Law of Conservation of Energy?  
The answer is that Simorg’s current implementation is ultimately constrained by the limitations of a digital emulator and physical hardware; the philosophical model and the practical implementation are related but not identical.
