blob: 437acd40a0965acd3987c843c4cd191fb657dcc3 (
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
|
Proposal to Merge `mmapmem` into `mapallmem`: Need Clarification on `data == 2`
I'm planning to merge `mmapmem` into `mapallmem` (see [commit 93ebb0c](https://github.com/devarajabc/box64/commit/93ebb0c58a434bb6c0f39503b88a8b9ee4047139)), by using the `data` field to indicate whether a memory fragment is allocated via `mmap`. Since all memory mapped in `mmapmem` is also mapped in `mapallmem`, maintaining both trees may cause memory redundancy.
In the proposed scheme:
- `data == 1`: Memory fragment is allocated.
- `data == 2`: Memory fragment is allocated by `mmap`.
However, I noticed that the `data` field is already being assigned the value `2` in the `reverveHigMem32()` function
```c
//src/custommem.c
void reverveHigMem32(void) {
// -- skipped --
rb_set(mapallmem, (uintptr_t)cur, (uintptr_t)cur + cur_size, 2);
// -- skipped --
}
```
I couldn't find any documentation or code that clearly distinguishes this usage of `data == 2` in `mapallmem.`
So my question is: what does `data == 2` represent in this context?
Alternatively, would it be acceptable if I use `data == 3` in `mapallmem` to indicate memory fragments allocated by `mmap`?
To test this approach, I ran `chess.exe` with `box64` ([commit 93ebb0c](https://github.com/devarajabc/box64/commit/93ebb0c58a434bb6c0f39503b88a8b9ee4047139)) and `wine` (same config as in [issue #2511](https://github.com/ptitSeb/box64/issues/2511)).
Below is the result after merging `mmapmem` into `mapallmem`:
Compare to Box64 (v0.3.5 73dfe869):
As shown above, the total number of red-black tree nodes was reduced by approximately 81.
Since each node occupies 56 bytes, this translates to a memory saving of roughly 4.4 KB, which can become more significant when running larger programs with extensive memory mappings.
|