Arena Allocator in Go

An arena allocator, also known as a pool allocator, is a memory allocation strategy that allocates a large chunk of memory upfront (the "arena") and then manages allocations within that arena. This approach can be significantly faster than traditional heap allocation, especially for short-lived objects, as it avoids the overhead of repeatedly calling the system's memory allocator. This challenge asks you to implement a basic arena allocator in Go.

Problem Description

You are tasked with implementing a simple arena allocator in Go. The arena allocator should provide the following functionalities:

Initialization: An Arena should be initialized with a specified size in bytes.
Allocation: An Allocate method should allocate a block of memory of a given size within the arena. It should return a pointer to the allocated block if successful, and nil if there is insufficient memory.
Deallocation: An Arena should automatically deallocate all allocated blocks when it is garbage collected (i.e., no longer referenced). This is handled implicitly by Go's garbage collector.
Reset: A Reset method should reset the arena, freeing all currently allocated blocks and making the arena available for new allocations. This should not reallocate the underlying memory; it should simply reset the allocation pointer.

The arena should maintain an internal pointer to track the next available memory location. All allocations should be contiguous within the arena.

Key Requirements:

The arena should be implemented as a struct.
The Allocate method should return a unsafe.Pointer to the allocated memory. This is necessary to allow for type-agnostic allocation.
Error handling: Return nil if allocation fails due to insufficient memory.
Memory safety: Ensure that allocations do not exceed the arena's capacity.

Expected Behavior:

Multiple allocations should be possible within the arena, as long as the total size of allocated blocks does not exceed the arena's capacity.
The Reset method should effectively clear the arena, allowing for reuse.
The arena should be garbage collected when no longer referenced.

Edge Cases to Consider:

Allocation size is zero.
Allocation size is larger than the remaining available memory in the arena.
Multiple concurrent allocations (although this challenge doesn't require thread safety, consider the implications).

Examples

Example 1:

Input: Arena arena(1024); arena.Allocate(100); arena.Allocate(200);
Output: p1 != nil, p2 != nil
Explanation: Two blocks of 100 and 200 bytes are successfully allocated within the 1024-byte arena. p1 and p2 are pointers to the allocated memory.

Example 2:

Input: Arena arena(512); arena.Allocate(200); arena.Allocate(400);
Output: p1 != nil, p2 == nil
Explanation: A 200-byte block is allocated.  Attempting to allocate a 400-byte block fails because only 312 bytes remain (512 - 200). p1 is a pointer to the first allocation, p2 is nil.

Example 3: (Reset)

Input: Arena arena(1024); arena.Allocate(100); arena.Allocate(200); arena.Reset(); arena.Allocate(50);
Output: p1 != nil, p2 != nil, p3 != nil
Explanation: Two blocks are allocated. `Reset()` clears the arena. A new 50-byte block is then successfully allocated.

Constraints

The arena size will be a positive integer between 1024 and 1048576 (1MB) bytes.
Allocation sizes will be positive integers between 1 and 100000 bytes.
The solution should be reasonably efficient. While absolute performance is not the primary focus, avoid unnecessary overhead.
The solution must be written in Go.

Notes

You will need to use unsafe.Pointer to allocate raw memory. Be extremely careful when working with unsafe.Pointer to avoid memory safety issues.
Consider using a simple linear allocation strategy for this challenge. More sophisticated strategies (e.g., splitting blocks) are not required.
Think about how to track the remaining available memory in the arena.
The Reset method should be efficient; it should not involve reallocating the underlying memory. It should simply reset the allocation pointer.
This is a simplified arena allocator. Real-world arena allocators often include features like alignment, metadata tracking, and thread safety. These are beyond the scope of this challenge.