Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The curious case of a memory leak in a Zig program

iamkroot.github.io

Post reply on HN
Print view View original

1–10 of 80 posts

Re: The curious case of a memory leak in a Zig program

#5

Post by jpcfl »

glandium wrote: post #3

TL;DR: the author had to figure out the hard way that Zig's FixedBufferAllocator is a bump allocator, and that it doesn't reuse freed memory except when it's the last allocation.

What an awful API design choice. It’s a stack allocator that leaks your memory if you don’t free in reverse order. Why would anybody ever want that behavior, let alone as the default?

Re: The curious case of a memory leak in a Zig program

#6

Post by Iridescent_ »

jpcfl wrote: post #5
glandium wrote: post #3

TL;DR: the author had to figure out the hard way that Zig's FixedBufferAllocator is a bump allocator, and that it doesn't reuse freed memory except when it's the last allocation.

What an awful API design choice. It’s a stack allocator that leaks your memory if you don’t free in reverse order. Why would anybody ever want that behavior, let alone as the default?

Because this is a specific allocator different from the general purpose allocator which is the "default" option. It is aimed at some specific use cases, when developers want to fine-tune their allocation strategies.

Re: The curious case of a memory leak in a Zig program

#7

Post by renox »

jpcfl wrote: post #5
glandium wrote: post #3

TL;DR: the author had to figure out the hard way that Zig's FixedBufferAllocator is a bump allocator, and that it doesn't reuse freed memory except when it's the last allocation.

What an awful API design choice. It’s a stack allocator that leaks your memory if you don’t free in reverse order. Why would anybody ever want that behavior, let alone as the default?

It's not the 'default' it's the behaviour of this allocator.

This makes this allocator fast, but it should clearly be named/described I agree.

Re: The curious case of a memory leak in a Zig program

#8

Post by mitulvohra »

Iridescent_ wrote: post #6
jpcfl wrote: post #5

Earlier quoted context omitted.

What an awful API design choice. It’s a stack allocator that leaks your memory if you don’t free in reverse order. Why would anybody ever want that behavior, let alone as the default?

Because this is a specific allocator different from the general purpose allocator which is the "default" option. It is aimed at some specific use cases, when developers want to fine-tune their allocation strategies.

I get that it is a specific allocator for niche use cases but i think it would be better that free throws some exception if it is done out of order rather than just being a no-op and making the programmer figure it out.

Re: The curious case of a memory leak in a Zig program

#9

Post by masklinn »

mitulvohra wrote: post #8
Iridescent_ wrote: post #6

Earlier quoted context omitted.

Because this is a specific allocator different from the general purpose allocator which is the "default" option. It is aimed at some specific use cases, when developers want to fine-tune their allocation strategies.

I get that it is a specific allocator for niche use cases but i think it would be better that free throws some exception if it is done out of order rather than just being a no-op and making the programmer figure it out.

I think the out of order bit is fine, in most cases it’s not an issue and may even be necessary. Your proposal would be straight up incompatible with most collections, and greatly limiting to the rest.

But it should be clearly spelled out.

When your type is already called

    FixedBufferAllocator
You can probably extend it to

    FixedBufferBumpAllocator
And now the implications are more searchable and clearer.
Post reply on HN