7 Jun
2022
7 Jun
'22
7:48 p.m.
On 6/7/22 14:46, Rémi Bernon (@rbernon) wrote:
On Tue Jun 7 19:33:23 2022 +0000, **** wrote:
Zebediah Figura replied on the mailing list:
On 6/7/22 13:33, Rémi Bernon wrote: > typedef struct > { > + SIZE_T __pad[sizeof(SIZE_T) / sizeof(DWORD)]; > struct list entry; /* entry in heap large blocks list */ > SIZE_T data_size; /* size of user data */ > SIZE_T block_size; /* total size of virtual memory block */ > - DWORD pad[2]; /* padding to ensure 16-byte alignment of data */ > + void *user_value; > DWORD size; /* fields for compatibility with normal arenas */ > DWORD magic; /* these must remain at the end of the structure */ > } ARENA_LARGE; Doesn't this end up wasting space on 64 bits? I.e. the structure is already aligned to a multiple of 16 bytes without any padding. (Also, somewhat out of curiosity, why move the member?)It makes the large block header size match native size, of `8 * sizeof(void *)`.
Moving the member makes the struct layout closer to SUBHEAP, and I think the same struct could be use for both later. Native has a concept of heap region, which seems to correspond to both large blocks and SUBHEAP at the same time. For instance only growable heap let you allocate large blocks.
Okay, makes sense.
In the future I guess it'd be nice to see that spelled out in the patch, or perhaps ideally as separate patches; that'd help make things clearer.