Region-based allocation for AST nodes

[SIGMazer]

Description

As the AST grows more complex, managing it becomes increasingly difficult, and free_ast becomes larger. This PR introduces a single Region to allocate all AST nodes, allowing them to be freed at once, simplifying memory management and reducing overhead.

Related Issue

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Performance improvement
• Refactor

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have documented my changes in the code or documentation
• I have added tests that prove my changes work (if applicable)
• I have run the unit tests locally
• I have run the valgrind memory tests locally
• All new and existing tests pass

[SIGMazer]

@araujo88 can you take a look

[leo-aa88]

@SIGMazer can you explain in more detail how this region-based allocation works? Or provide a reference?

[SIGMazer]

@SIGMazer can you explain in more detail how this region-based allocation works? Or provide a reference?

We pre-allocate a memory chunk (Arena) and use it to allocate all ASTNode instances. This approach allows us to free the entire Arena at once, instead of traversing each ASTNode individually and freeing them one by one.

Reference

• https://en.wikipedia.org/wiki/Region-based_memory_management
• https://www.gingerbill.org/article/2019/02/08/memory-allocation-strategies-002/

[leo-aa88]

@SIGMazer can you explain in more detail how this region-based allocation works? Or provide a reference?

We pre-allocate a memory chunk (Arena) and use it to allocate all ASTNode instances. This approach allows us to free the entire Arena at once, instead of traversing each ASTNode individually and freeing them one by one.

Reference

* https://en.wikipedia.org/wiki/Region-based_memory_management

* https://www.gingerbill.org/article/2019/02/08/memory-allocation-strategies-002/

Very interesting! I wasn't familiar with that approach. Should we be concerned with the disadvantages? I understand that, as for the current usages of brainrot right now (which are small programs) this shouldn't be a concern.

Region-based memory management works best when the number of regions is relatively small and each contains many objects; programs that contain many sparse regions will exhibit internal fragmentation, leading to wasted memory and a time overhead for region management. Again, in the presence of region inference this problem can be more difficult to diagnose.

[SIGMazer]

@SIGMazer can you explain in more detail how this region-based allocation works? Or provide a reference?

We pre-allocate a memory chunk (Arena) and use it to allocate all ASTNode instances. This approach allows us to free the entire Arena at once, instead of traversing each ASTNode individually and freeing them one by one.

Reference

* https://en.wikipedia.org/wiki/Region-based_memory_management

* https://www.gingerbill.org/article/2019/02/08/memory-allocation-strategies-002/

Very interesting! I wasn't familiar with that approach. Should we be concerned with the disadvantages? I understand that, as for the current usages of brainrot right now (which are small programs) this shouldn't be a concern.

Region-based memory management works best when the number of regions is relatively small and each contains many objects; programs that contain many sparse regions will exhibit internal fragmentation, leading to wasted memory and a time overhead for region management. Again, in the presence of region inference this problem can be more difficult to diagnose.

I don't think this affects our case because we allocate a single contiguous region for all AST allocations, meaning we won't encounter any sparse regions. In the future, if we need to delete or transform nodes before freeing the entire Arena, we can introduce optimizations such as merging underutilized regions. Alternatively, we could use a bump allocator, which treats the region as a stack to avoid fragmentation. However, in our current case, I believe our implementation will not face any issues.