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

Arena allocator tips and tricks

nullprogram.com

Post reply on HN
Print view View original

81–90 of 99 posts

Re: Arena allocator tips and tricks

#81

Post by Someone »

gpderetta wrote: post #72
amalcon wrote: post #50

Earlier quoted context omitted.

Interestingly (confusingly), Linux's OOM killer is invoked for a different notion of OOM than a null return from malloc / bad_alloc exception. On a 64-bit machine, the latter will pretty much only ever happen if you set a vsize ulimit or you pass an absurd size into malloc. The OOM killer is the only response when you actually run out of memory. If you want to avoid your program triggering the OOM killer all on its o…

I wonder if it is possible to avoid OOM by making sure that all allocations are done from a named (on disk, not shm) memory file. This way in principle is always possible to swap to disk and never overcommit. I guess in practice the kernel might be in such dire straits that it is not able to even swap to disk and might need to kill indiscriminately.

That would have to be all allocations in all processes (and the kernel and drivers)

In extreme circumstances, the OOM killer can decide to kill your process even if it barely uses any memory (a simple way to get there is by fork-bombing copies of such processes)

Also, using oom_score_adj (https://www.baeldung.com/linux/memory-overcommitment-oom-kil...) is a lot easier.

Re: Arena allocator tips and tricks

#82

Post by chatmasta »

Are there security issues with not zeroing out the previously used memory when "releasing" a buffer (moving the offset)? I'm not a systems programmer, so I guess I just assumed that most malloc implementations also zeroed out memory when freeing it, but a quick Google suggests that's not actually the case (with typical malloc implementations "getting their pages from /dev/zero" [0], effectively zeroing memory at allocation time rather than when freeing it).

[0] https://superuser.com/a/894508

Re: Arena allocator tips and tricks

#83

Post by dev_dwarf »

londons_explore wrote: post #40

Having to decide ahead of time how much memory to allocate to the arena is... crap... The vast majority of programmers don't want arbitrary 'out of memory in arena' errors just because the user inputted slightly more things than expected. Yes, I know that modern OS's don't actually allocate memory till you use it, but when you make widespread use of that functionality, typically your reuse of address space is poor an…

Your second paragraph doesn't make sense because the whole point of this type of allocation is to guarantee that you will reuse the same address space you just freed.

Re: Arena allocator tips and tricks

#84

Post by titzer »

chatmasta wrote: post #82

Are there security issues with not zeroing out the previously used memory when "releasing" a buffer (moving the offset)? I'm not a systems programmer, so I guess I just assumed that most malloc implementations also zeroed out memory when freeing it, but a quick Google suggests that's not actually the case (with typical malloc implementations "getting their pages from /dev/zero" [0], effectively zeroing memory at allo…

> Are there security issues with not zeroing out the previously used memory

Yes, there can be. Security-critical software often does this explicitly, and it's been a bug when compilers have removed the zeroing by reasoning that unreachable memory is unreachable...leading to crypto secrets floating in memory unnecessarily.

For languages like Java and Go where objects are at least zero-initialized before the constructor(s) run, usually the allocator just zeroes the entire TLAB before allocation.

Re: Arena allocator tips and tricks

#85

Post by astrange »

squeek502 wrote: post #52
olodus wrote: post #47

Earlier quoted context omitted.

Oh wow that is a really interesting test solution. That would be an interesting thing to add to all zig tests (I know they already have the testing allocator and good valgrind support but I don't think that tests/simulates oom). I love things like these that use existing tests and expand the to just test further thing in already covered flows. We have done similar things at my work where we test expansion of data mod…

There's support for exactly this type of OOM testing in Zig via std.testing.checkAllAllocationFailures: - https://github.com/ziglang/zig/blob/1606717b5fed83ee64ba1a91... - https://www.ryanliptak.com/blog/zig-intro-to-check-all-alloc...

This is a clear sign of a badly designed language. You should never see a fixed-size (less than page size) allocation fail, simply because there's nothing you can reasonably do if it does fail. Either you should crash or it should block until it is possible again.

(Where crash means a worker process or something limited to something less than the entire system. See Erlang for the logical extension of this.)

I realize this implies Windows and Java are badly designed and my answer to that is "yes".

Re: Arena allocator tips and tricks

#86

Post by saagarjha »

mtzet wrote: post #60
saagarjha wrote: post #59

Earlier quoted context omitted.

Wait until someone tells Linus about how processors do reordering. (Yes, I know he understands it. Clearly he just refuses to accept that compilers can also reorder his code and he needs to accommodate that.)

Processors doing out-of-order execution doesn't change the semantics of the code. That's very different from the example where gcc just throws away the assignment. The idea that he just needs to accommodate the compiler people is silly. Compilers exist to serve programmers, not the other way around. It's entirely reasonable to disagree with the compiler developers and use a flag to disable behaviour your don't want.

It does when you have a weak memory model and multiple threads involved.

Re: Arena allocator tips and tricks

#87

Post by matheusmoreira »

saagarjha wrote: post #59
matheusmoreira wrote: post #32

Earlier quoted context omitted.

Welp. Linus Torvalds was right about this stuff. https://lwn.net/Articles/316126/ https://lkml.org/lkml/2003/2/26/158

Wait until someone tells Linus about how processors do reordering. (Yes, I know he understands it. Clearly he just refuses to accept that compilers can also reorder his code and he needs to accommodate that.)

> he needs to accommodate that

Clearly he doesn't. He just disabled harmful features and called it a day. Stuff like strict aliasing and undefined signed integer overflow apparently do nothing but serve as an excuse for the optimizer to screw up perfectly reasonable code.

https://cellperformance.beyond3d.com/articles/2006/06/unders...

https://stackoverflow.com/q/2958633/512904

Looks like this is a pretty good approach to fixing the C language. Take the nonsensical undefined stuff and tell the compiler to define it.

Looks like there is a may_alias type attribute to tell GCC that some types may alias:

https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.ht...

I'm not sure if it's worth the effort though. Too much uncertainty.

Re: Arena allocator tips and tricks

#88

Post by saagarjha »

patrec wrote: post #71
saagarjha wrote: post #10

> Unsigned sizes are another historically common source of defects, and offer no practical advantages in return. Case in point exercise for the reader: Change each ptrdiff_t to size_t in alloc, find the defect that results, then fix it. I know that it’s a different “kind” of defect, but none of the code has overflow checks even with ptrdiff_t…

Why would it need overflow checks when subtracting two valid pointers?

The overflow is in size * count

Re: Arena allocator tips and tricks

#89

Post by matheusmoreira »

astrange wrote: post #85
squeek502 wrote: post #52

Earlier quoted context omitted.

There's support for exactly this type of OOM testing in Zig via std.testing.checkAllAllocationFailures: - https://github.com/ziglang/zig/blob/1606717b5fed83ee64ba1a91... - https://www.ryanliptak.com/blog/zig-intro-to-check-all-alloc...

This is a clear sign of a badly designed language. You should never see a fixed-size (less than page size) allocation fail, simply because there's nothing you can reasonably do if it does fail. Either you should crash or it should block until it is possible again. (Where crash means a worker process or something limited to something less than the entire system. See Erlang for the logical extension of this.) I realize…

So if my browser tries to allocate memory for a tab and the allocation fails it should just crash or block instead of handling the failure gracefully by not creating a new tab and telling me the system is running low on memory?

Re: Arena allocator tips and tricks

#90

Post by saagarjha »

matheusmoreira wrote: post #87
saagarjha wrote: post #59

Earlier quoted context omitted.

Wait until someone tells Linus about how processors do reordering. (Yes, I know he understands it. Clearly he just refuses to accept that compilers can also reorder his code and he needs to accommodate that.)

> he needs to accommodate that Clearly he doesn't. He just disabled harmful features and called it a day. Stuff like strict aliasing and undefined signed integer overflow apparently do nothing but serve as an excuse for the optimizer to screw up perfectly reasonable code. https://cellperformance.beyond3d.com/articles/2006/06/unders... https://stackoverflow.com/q/2958633/512904 Looks like this is a pretty good approac…

That's not how they work but I doubt getting into an argument with you about how undefined behavior works with someone who is dead-set on it being harmful is going to be productive.
Post reply on HN