I have a revolutionary plan for avoiding hitching in my game engine due to frequent mallocs:

I'm just gonna preallocate a few gigs and disable purging, never giving the memory back to the system xD

Fuck you system! I will forever stay inside my process, you're syscalls can't screw my frame times now!

ram arena

I know words!

I mean, that sounds pretty solid, can't you tell your runtime or allocator to hold onto a certain base amount of memory even if a significant portion could be freed?

that's quite a valid approach for frequently used memory

PS: allocating memory during draws is a bad idea anyway

@12bitfloat what @jestdotty says. It's very common with graphic stuff in general. Nice wheel tho. Round enough? 😁

@retoor Yeah but thats too much work, Im lazy

I'm just gonna use mimalloc as my arena, surely nothing will go wrong

@lorentz That's the plan!

Use mimalloc and disable purging so it'll never tell the OS when pages aren't needed anymore. This way all the memory I need stays in the (hopefully very fast) mimalloc caches

Do I understand, based on this, that you're using the language of angels?

@retoor Sorry, should've written I'm Box::new()'ing all my memory ;P

For fun I wanted to see what happens during allocations to the ram. So I allocated a bunch of ram and wrote a specific value to all locations. Then I allocated (using C++ feature) locations within this memory. So I could view this memory and see what gets initialized and what does not. It is a neat feature to understand ram allocated on the heap. Not sure if this can be done with stack memory allocation.

Does Rust allow allocations in memory you reserved? So you can manage your own memory allocations?

I know console devs do this kind of thing and overwrite ram for objects. Using preallocated object slots.

@Demolishun Kinda... Normal types are easy but dynamically sized containers are of course always hard. There's an unstable allocator API for containers I guess I could use

But my thinking is: mimalloc already is a kind of arena allocator (allocations are grouped into size classes) and it's thread-local and super fast, no locking at all

So... as long as it doesn't interact with the OS a bunch it's essentially a really fast, generic arena allocator not much different from one I'd write myself

And most importantly: I can be lazy and just use std containers :P

@12bitfloat even standard malloc is an arena allocator, but not always. there are two algorithms in use, one of which is basically a bunch of arenas

@iiii I know but the problem often is internal locking and it doing syscalls. I don't want it to start MADV_DONTNEED'ing 100 pages when I allocate during a frame

@12bitfloat fair nuff. using alternatives is a good idea in this case

PS: also, don't allocate during frames. use object pools or something like that

@iiii Yeah I just read the mimalloc source and I don't think even with purging disabled I could use it for this purpose. Every 1000 and 10000 allocations it does bigger bookkeeping of collecting the heaps for unused blocks

You're right, ultimately I should build a stack/linear allocator for temporary objects which I can just clear between frames

@12bitfloat what you've described is what people call "an arena". Just FYI what to search for on the web

Does Rust have a way to do in place allocation? I think that is what it is called in C++ when allocating on existing reserved memory.

@Demolishun The closest thing in Rust is MaybeUninit, at least that's what Box and other std types use internally.

@Demolishun I mean, Allocator returns a NonNull<[u8]> which is unceremoniously cast() into a NonNull<MaybeUninit<T>> and the rest after that pretty much follows high level Rust logic.

@iiii Bruh I know what an arena is. I'm just too lazy to implement one :D

@Demolishun placement-new is still debated in Rust. Right now it *can* happen due to optimizations but there's no formal rule like in cpp. There are some ideas around placement-by-return (if i remember correctly) but that's still in the idea stage

@Demolishun Really the issue is how do you make it compose? One level is fine I guess: `*target = Foo {..};` or `*target = init();` (where init straight returns a Foo) are fine. But if it get's more complicated than that how do you square the semantics of placement-new with your already existing semantics of object lifetime and new

(I'm actually not sure, and I don't know the precise rules of cpp, but knowing cpp I would guess that they are pretty arbitrary in the first place lol)

@12bitfloat in C++ its probably not just one stick of dynamite, but 5.