Skip to content

Better memory management#100

Open
Marco012 wants to merge 6 commits intoz-libs:mainfrom
Marco012:allocators
Open

Better memory management#100
Marco012 wants to merge 6 commits intoz-libs:mainfrom
Marco012:allocators

Conversation

@Marco012
Copy link

The purpose of this PR is to improve the memory management.
Right now, Zen C is bound to malloc/free functions. Well, on a big project, this might be a very big problem. To fix this, I suggest being able to implement custom allocators and be able to specify which allocator should be used when we need to handle manual memory allocation.

The problem that we get out of this is knowing which allocator was used for each value, and right now the only option I see is keeping a reference to the allocator on the value, which adds a tremendous overhead for tiny values:

struct Box<T> {
    ptr: T*;
    allocator: Allocator*;
}

impl Drop for Box<T> {
    fn drop(self) {
        self.allocator.free(self);    
    }
}

So what also could be done is having a mirrored type that doesn't have the allocator like this:

struct Box<T> {
    ptr: T*;
}

Still I highly suggest replacing the current alloc functions into allocators. Implementing a Debug allocator that keeps track and detects memory leaks and stuff.
Also, Box now implements the Drop trait. No need to manually call the free() function, and I highly suggest its removal.

@Marco012
Copy link
Author

At the moment, inner values implementing Drop are not dropped.

struct StringHolder {
    s: String;
}

fn test_string_holder(allocator: DebugAllocator*) {
    var h = StringHolder {
        s: String::from("hello")
    };
}

In the code above, the variable h will not drop the string, we have to manually impl the Drop trait for StringHolder and call the drop function on the string.
Even more complex are the generic structs. While we can just impl Drop for simple structs like that one, that is not possible with a Vec<T> for example. T could be an i32 or a String, we never know. An idea would be to allow this:

impl Drop for Vec<T: Drop>: {
    fn drop(self) {
        // Iterate all and call element.drop();
    }
}

But then issues with moving values start arising, such as:

fn test_vec_box_string(allocator: DebugAllocator*) -> Box<String> {
    var vec = Vec<String>::new();

    for i in 0..100 {
        vec.push(String::from("hello"));
    }

    return vec.get(4);
}

In the code above, if the array is dropped and all elements are dropped, the element 4 would become invalid.

@Zuhaitz-dev Zuhaitz-dev self-assigned this Feb 6, 2026
@Zuhaitz-dev Zuhaitz-dev added enhancement New feature or request good first issue Good for newcomers labels Feb 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request good first issue Good for newcomers

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants