3 ms·
Right, the ability to relocate a chunk of memory to a new virtual address (with more capacity at the end) without doing a physical copy would be an interesting
by kabdib 4y ago
Right, the ability to relocate a chunk of memory to a new virtual address (with more capacity at the end) without doing a physical copy would be an interesting way to solve the problem.
I don't know if anyone has done research on integrating data structures and OS functionality in this way. Interesting idea.
We needed to get things running again rather quickly, though :-)
- cyber_kinetist 4y agoSome game engine developers have certainly used this idea, to prevent any reallocations when the dynamic array needs to be resized. Such as: https://ruby0x1.github.io/machinery_blog_archive/post/virtual-memory-tricks/index.html https://ruby0x1.github.io/machinery_blog_archive/post/virtua... Some ECS implementations use this to reduce the overhead of dynamic arrays, as well as ensuring pointer stability of the items stored. For example entt: https://skypjack.github.io/2021-06-12-ecs-baf-part-11/ https://skypjack.github.io/2021-06-12-ecs-baf-part-11/ And here's a library implementing a resizable, pointer-stable vector using virtual memory functionality from the OS: https://github.com/mknejp/vmcontainer https://github.com/mknejp/vmcontainer
- ultrahax 4y agoEnd of page allocation has been a real life-saver. I have it rigged up to the core allocators of the game engine I work with, so you can switch it with a cmdline switch; if you suspect an overwrite, you switch on the EOP allocator ( using more memory temporarily ), and bang, you get a segfault where you went off the end / used-after-free.