Why does Box64 use a fixed 128 bitmap for small allocations?

[devarajabc]

In src/custommem.c the function:

void* map128_customMalloc(size_t size, int is32bits) {
    size = 128;
    …
}

hard-codes every allocation to 128 bytes. However, In my profiling (box64 + wine just like #2511 ) most allocation requests are far smaller (e.g. ≤ 56 bytes), so this can increase internal fragmentation.

4	1030
8	85
16	716
32	268
40	14
56	7998
64	34
96	81
120	1152
128	24

Questions:

1. What was the original design rationale for fixing the block size at 128?

2. Is it for alignment, page-size granularity, mmap overhead, or something else?

3. Would it be beneficial to reduce this to 64?

I’m happy to draft a PR to change the default to 64 if that would help.

Environment

1. Box64 version: Box64 riscv64 v0.3.7 926a5980 with Dynarec built on Jun 13 2025
2. Build flags:

cmake -G Ninja \
-DBOX32=ON \
-DRV64=1 \
-DRV64_DYNAREC=ON \
-DGDBJIT=ON \
-DCMAKE_BUILD_TYPE=RelWithDebInfo \
-DCMAKE_C_COMPILER=gcc \
..

3. Platform: RISC-V 64, Debian (chroot)
4. CPU: 4× cores(Andes AX45MP), Little Endian
5. page size 4096
6. Kernel: 6.1.47+
7. gcc :(Debian 14.2.0-19) 14.2.0
8. glibc :(Debian GLIBC 2.41-7) 2.41

Thanks!

[ptitSeb]

Rationnale was: simplicity vs speed.

Adding a 64bytes bitmap allocator is doable, and quite easy, but that's a lot of code for a limited benefit.

Even memory-wise, adding a 64bytes allocator would not save much. In your example, that would 64*10145 so around 634k... Not even a megabytes.

Feel free to add a 64bytes allocator if you want, via a PR...