blob: 31b8a12a0c7cd72d042de7a43545434a41753fe5 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
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!
|