Wrapping an allocator to know how many bytes it has allocated

Etienne_Parmentier · June 17, 2025, 4:36pm

Hi ! I am following ‘Crafting Interpreters’ by bob nystrom and inside the book, there is a function that counts how many bytes were allocated by the VM. I want to use an allocator, but I did not find a way to get how much memory has been allocated when reading all of the function that were proposed in the interface. I don’t want to restrict myself to an allocator that does keep track of the count, so I would like to wrap a generic allocator. I am not familliar at all with interfaces in zig, how would one create such allocator ?

Southporter · June 17, 2025, 6:05pm

When I was going through that book, I came up with an allocator wrapper to do the bytes tracking. One note: this was written with 0.13 so some things have changed since then. (I should probably do an upgrade…)

github.com/Southporter/zlox

src/memory.zig

c8bad03fd


      
          }
          
          pub fn bookkeeping(manager: *Manager, size_t: usize, amount: usize) Error!void {
              log.debug("allocating {d} bytes\n", .{size_t * amount});
              manager.bytes_allocated += size_t * amount;
              if (!manager.is_collecting and manager.bytes_allocated > manager.next_gc) {
                  try manager.collect();
              }
          }
          
          pub fn alloc(ctx: *anyopaque, n: usize, log2_ptr_align: u8, ra: usize) ?[*]u8 {
              var manager: *Manager = @ptrCast(@alignCast(ctx));
              const ptr_align = @as(usize, 1) << @as(std.mem.Allocator.Log2Align, @intCast(log2_ptr_align));
          
              manager.bookkeeping(ptr_align, n) catch |e| {
                  log.err("Error running bookkeeping in alloc: {any}\n", .{e});
              };
              return manager.arena.allocator().vtable.alloc(&manager.arena, n, log2_ptr_align, ra);
          }
          
          pub fn resize(ctx: *anyopaque, buf: []u8, log2_buf_align: u8, new_len: usize, ret_addr: usize) bool {

This allowed me to set up the backing allocator however I wanted. I could use a Debug/GeneralPurpose allocator or an arena.

The main functions required by the Allocator interface are:
alloc, resize, and free. Then your wrapping allocator can expose an allocator() method that returns the vtable implementation with pointers to your wrapper’s implementations.

github.com/Southporter/zlox

src/memory.zig

c8bad03fd


      
              return manager.arena.allocator().vtable.resize(&manager.arena, buf, log2_buf_align, new_len, ret_addr);
          }
          
          pub fn free(ctx: *anyopaque, buf: []u8, log2_buf_align: u8, ret_addr: usize) void {
              var manager: *Manager = @ptrCast(@alignCast(ctx));
              log.debug("{*} freeing {d} bytes\n", .{ buf, buf.len });
              manager.bytes_allocated -= buf.len;
              manager.arena.allocator().vtable.free(&manager.arena, buf, log2_buf_align, ret_addr);
          }
          
          pub fn allocator(manager: *Manager) std.mem.Allocator {
              return .{
                  .ptr = manager,
                  .vtable = &.{
                      .alloc = alloc,
                      .free = free,
                      .resize = resize,
                  },
              };
          }

Justus2308 · June 17, 2025, 6:22pm

For some inspiration, have a look at std.testing.FailingAllocator. It implements many different kinds of basic bookkeeping about the allocations it does (and their eventual failure, you probably don’t want to take inspiration from that part… ).

squeek502 · June 17, 2025, 9:59pm

Another example:

github.com/nektro/gimme

src/CountingAllocator.zig

master

const std = @import("std");
const CountingAllocator = @This();

child_allocator: std.mem.Allocator,
count_active: u64,
count_total: u64,
count_allocs: u64,
count_allocs_success: u64,
count_resizes: u64,
count_frees: u64,

pub fn init(child_allocator: std.mem.Allocator) CountingAllocator {
    return .{
        .child_allocator = child_allocator,
        .count_active = 0,
        .count_total = 0,
        .count_allocs = 0,
        .count_allocs_success = 0,
        .count_resizes = 0,
        .count_frees = 0,

This file has been truncated. show original

(it’s written in a file-as-a-struct way)

g41797 · June 18, 2025, 4:21am

Looks like we don’t take multithreading upon consideration.

Let’s suppose that wrapped allocator is already thread-safe.

It does not mean, that we don’t need to guard wrapper (decorator) calculations.

std already has thread-safe wrapper and you can use it as template or directly as wrapper for your wrapper

And in this chain of wrappers we immediately have perfomance hit, because chain of mutexes

Ofcourse we can wrap non thread-safe allocator, but in usual flow(we got allocator from caller) we cannot prevent this chain

Etienne_Parmentier · June 18, 2025, 8:30am

This should listed in some sort of example section, these smol allocators are so usefull !! Thanks.

Etienne_Parmentier · June 18, 2025, 8:41am

Multithreading is out of the question for now, I have not planned to use it inside the VM. If I ever get to this point, I may give the VM it’s own allocator and use other ones for other tasks. I don’t plan to write huge programs with it yet, so multithreading may not be necessary.

What are chains of mutexes ? Are you pointing at the fact that taking two mutexes (one inside each wrapper) is necessarily slower than having just one, or is there a deeper problem ?

g41797 · June 18, 2025, 9:10am

exactly

Etienne_Parmentier · June 18, 2025, 3:55pm

I have finished to implement my wrapper, coding it helped me find a subtle issue where I was allocating memory using the wrapped allocator, but freeing it using my wrapper. It was nightmare-ish, I believed for a sec that I was freeing more memory than allocated, without any crash, or double free errors.
I will unsuscribe from this thread, thank you to everybody !!