7 Jun
2022
7 Jun
'22
7:46 p.m.
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.