[Question] Max contiguous allocation size limitations within custom Arenas

[emrahsungu]

First, thank you for the incredible work on mimalloc. I recently ported it to a proprietary game engine (20+ years old) for a modern console environment. (Thanks to your support at #1213) Due to the lowest-resourced newgen console😉, the arena and heap management have been vital for our performance.

I am observing a specific behavior regarding the maximum contiguous allocation size allowed within a custom arena.

The Setup:
I am using mi_arena_alloc to reserve a large block of memory, then creating heaps associated with that arena_id to categorize allocations (e.g., Physics, Textures). (X,Y,Z... sized M different arenas)

The Issue:
I've noticed a correlation between the total Arena size and the maximum possible contiguous allocation:
Arena Size < 2 GB: The maximum contiguous allocation (mi_heap_malloc) fails for anything larger than ~64 MB.
Arena Size > 3 GB: I can successfully allocate 1 GB of contiguous memory without issue.

mi_option_set(mi_option_disallow_os_alloc, 1);
size_t sizeArena = 2ull * 1024 * 1024 * 1024;
mi_arena_id_t id;
mi_manage_os_memory_ex(x, sizeArena , true, false, false, -1, false, &id);
auto heap = mi_heap_new_in_arena(id);
void* ptr{ nullptr };
ptr = mi_heap_alloc_new(heap, 512 * 1024 * 1024); //fails for 2gb arena
ptr = mi_heap_alloc_new(heap, 128* 1024 * 1024);  //fails for 2gb arena
ptr = mi_heap_alloc_new(heap, 64* 1024 * 1024);   //fails for 2gb arena

Questions:

Is there a specific constant or internal "Region" logic that limits contiguous allocations to the segment size (64 MB) when the total Arena pool is below a certain threshold?

Is there a recommended way to fine-tune the segment/region mapping for custom arenas to allow large contiguous allocations (e.g., for large streaming buffers) without needing to over-reserve the total arena size?

Is this intended behavior, or is it a side effect of how MI_ARENA_REGION_SIZE or similar internal macros interact with the total pool?

Any guidance on where to look in the source to adjust this behavior for restricted-memory environments would be greatly appreciated.

Similar question albeit a bit tangential
#1228

[emrahsungu]

Arena allocation fails for count > 2 due to disabled within-field bitmap search

Hi @res2k, @daanx 👋
I think this might be the reason:

Summary

Arena allocations fail when the requested block count is greater than 2, even though sufficient free blocks exist inside a single bitmap field.

This appears to be caused by a commented-out within-field search in src/bitmap.c, which forces the allocator to use the cross-field algorithm that requires leading zeros.

---

Minimal Reproduction

mi_option_set(mi_option_disallow_os_alloc, 1);
auto x = std::malloc(1ull * 1024 * 1024 * 1024);
mi_arena_id_t id;
mi_manage_os_memory_ex(x, 1ull * 1024 * 1024 * 1024,
                       true, false, false, -1, false, &id);
auto heap = mi_heap_new_in_arena(id);
mi_debug_show_arenas();

void* ptr{ nullptr };
do {
    ptr = mi_heap_alloc_new(heap, 512 * 1024 * 1024);
    mi_debug_show_arenas();
} while (true);

---

Observed Behavior

Allocation fails when fragmentation occurs within a bitmap field, even though enough contiguous free bits exist.

Example bitmap state:

0xffffffff80000001

Meaning:

• Bits 63–32: used
• Bits 1–30: FREE (30 blocks available)
• Bits 0 and 31: used

Then:

void* p = mi_heap_malloc(heap, 64 * 1024 * 1024);

• Requires 3 blocks (including overhead)
• Returns NULL ❌
• Even though 30 contiguous blocks are available inside the field

---

Suspected Cause

File: src/bitmap.c (around lines 307–312)

Inside:

bool _mi_bitmap_try_find_from_claim_across(..., const size_t count, ...) {
  ...
  for (size_t visited = 0; visited < bitmap_fields; visited++, idx++) {
    if (idx >= bitmap_fields) { idx = 0; }

    // ⚠️ THIS CODE IS COMMENTED OUT:
    /*
    if (count <= MI_BITMAP_FIELD_BITS) {
      if (_mi_bitmap_try_find_claim_field(bitmap, idx, count, bitmap_idx)) {
        return true;
      }
    }
    */

    // Goes directly here:
    if (mi_bitmap_try_find_claim_field_across(bitmap, bitmap_fields, idx, count, 0, bitmap_idx)) {
      return true;
    }
  }
}

For count <= MI_BITMAP_FIELD_BITS, the allocator should be able to satisfy the request entirely within a single bitmap field.

However, because the within-field search is commented out, it goes directly to the cross-field algorithm, which requires leading zeros and fails in fragmented-but-sufficient cases.

---

Testing After Fix

After uncommenting the within-field search:

• ✅ 64 MB allocation succeeds (3 blocks)
• ✅ 128 MB allocation succeeds (4 blocks)
• ✅ 512 MB allocation succeeds (16 blocks)

Behavior appears correct and consistent.

---

Questions

1. Is the commented-out within-field search intentional?
2. Is there a reason why the cross-field algorithm is forced even when count <= MI_BITMAP_FIELD_BITS?
3. Could this be an unintended regression in fragmented arena scenarios?

I'm currently using mimalloc v2.x (not 3.x), in a setup where OS allocation is disallowed and arenas are pre-managed.

Happy to provide additional repro details if needed.

Thanks for the great work on mimalloc!