Jeroen van Rijn beee27dec0 Allow core:mem/tlsf to automatically add new pools. ...

New features:
- If TLSF can't service an allocation made on it, and it's initialized with `new_pool_size` > 0, it will ask the backing allocator for additional memory.

- `estimate_pool_size` can tell you what size your initial (and `new_pool_size`) ought to be if you want to make `count` allocations of `size` and `alignment`, or in its other form, how much backing memory is needed for `count` allocations of `type` and its corresponding size and alignment.

2025-04-14 19:49:55 +02:00

..

tlsf

Allow core:mem/tlsf to automatically add new pools.

2025-04-14 19:49:55 +02:00

virtual

Merge pull request #4836 from laytan/fix-wrong-out-of-memory

2025-03-20 17:20:26 +00:00

alloc.odin

Add mem.make_over_aligned

2025-03-31 10:51:02 +01:00

allocators.odin

General clean up of code

2025-01-01 15:13:46 +00:00

doc.odin

Update doc.odin

2025-02-26 03:04:54 -06:00

mem.odin

Add mem.make_over_aligned

2025-03-31 10:51:02 +01:00

mutex_allocator.odin

build mutex allocator code on freestanding wasm

2024-10-14 16:11:25 +02:00

raw.odin

[mem]: Document mutex, rollback stack and tracking allocators

2024-09-14 10:46:35 +11:00

rollback_stack_allocator.odin

[mem]: Rollback allocator API consistency

2024-09-14 13:15:02 +11:00

tracking_allocator.odin

Makes tracking allocator default to crashing on a bad free instead of add to bad_free_array. The bad_free_array remains to not break old code. The new default behavior is implemented in a callback that you can override, there's a second provided callback that provides the old behavior where an element was added to bad_free_array. Rationale: Many people are just checking the allocation_map, but don't check the bad free array. Several examples throughout core that use tracking allocator don't check bad_free_array either, so people have been taught not to check it.

2024-12-21 15:49:48 +01:00