diff options
Diffstat (limited to 'results/scraper/box64/2740')
| -rw-r--r-- | results/scraper/box64/2740 | 61 |
1 files changed, 61 insertions, 0 deletions
diff --git a/results/scraper/box64/2740 b/results/scraper/box64/2740 new file mode 100644 index 000000000..31b8a12a0 --- /dev/null +++ b/results/scraper/box64/2740 @@ -0,0 +1,61 @@ +Why does Box64 use a fixed 128 bitmap for small allocations? +In `src/custommem.c` the function: +```c +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! + |