#ArenaAllocator question — whats actually happening with free?
1 messages · Page 1 of 1 (latest)
why? by "actually freed" I dont mean mean necessarily released to the operating system
released to the os? or just freed for the allocator implementation?
no, you would have to change the implementation to track that
why do you want to do this? Just for understanding arenas better?
you would have to change the arena implementation but yes you could track this.
well actually looking at your example this would not be a good use case for this. wasFreed could only work 100% of the time if the same memory is never reused by an identical allocation.
things like this require using handles instead of a pointer that keeps a some information (typically a generation id) as well as the pointer.
hard to awnser this. Maybe look at the doc comments in std.mem.Allocator.VTable to understand the allocator interface better
I just read the source code of std.heap.ArenaAllocator.free, it also says that it can free the most recent allocation in the ArenaAllocator doc comment as well though.
you mean std.heap.ArenaAllocator.free? or std.mem.Allocator.free?
not really, you really want to avoid making too many syscalls, so keeping memory around for future allocation instead of releasing it as soon as possible is typical.
why not? Its part of the contract of std.mem.Allocator that allocations that are freed are made invalid. For the implementation of ArenaAllocator there was an opportunity of being able to free the last allocation for cheap so it was taken.