Skip to content

bugfix(gamememory): Align memory pool allocations to 8 bytes - #637

Open
tintinhamans wants to merge 1 commit into
GeneralsOnlineDevelopmentTeam:mainfrom
tintinhamans:arctic/go/fix/memory-alignment-8
Open

tintinhamans wants to merge 1 commit into
GeneralsOnlineDevelopmentTeam:mainfrom
tintinhamans:arctic/go/fix/memory-alignment-8

Conversation

@tintinhamans

Copy link
Copy Markdown

The memory pools put a 12 byte header in front of each block and round sizes to 4, so the engine's operator new returns pointers that are 4 mod 8 about half the time. MSVC promises 8 on x86, and the original code already had a @todo srj -- make this work for 8 on it.

protobuf relies on that: RepeatedField keeps flags in the low bits of its heap pointer, so on our heap it frees a pointer 4 bytes early. That crashed GNS, which is linked into the exe. DLLs use their own CRT new and are not affected.

MEM_BOUND_ALIGNMENT is now 8 and the header (plus the leading wall in debug) is padded to a multiple of 8 in one place, SINGLEBLOCK_USERDATA_OFFSET. Debug builds assert the alignment, and the pool size asserts compare against the rounded size. The blob count check keeps its 4, that rule is about pool counts, not alignment. Both the Generals and Zero Hour copies are changed.

This costs about 4.5 MB (~8%) of initial pool memory on Zero Hour, measured on upstream's pool tables. Nothing in the simulation orders or hashes by pointer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant