...since compilers like MSVC assume allocation functions return 16-bit alignment.
This causes issues with messages that have fields aligned (via __declspec() or alignas()) to 16-bytes, since the compiler
assumes allocated structs will be placed on a 16-byte boundary, but tlsf_malloc() only guarantees an 8-byte alignment so
a member declared inside a Yojimbo message with 16-byte alignment might end up at an 8-byte boundary.
This has a tiny cost of the occasional additional 8-bytes of waste per allocation, but in practice I've seen this
to be within noise. Debugging an issue like this might be unobvious for non-senior engineers, so I think the cost is
justified.
@gafferongames Any reasons this isn't being merged? It fixes actual production issues with yojimbo messages that contain member with alignas() requirements.
...since compilers like MSVC assume allocation functions return 16-bit alignment.
This causes issues with messages that have fields aligned (via __declspec() or alignas()) to 16-bytes, since the compiler assumes allocated structs will be placed on a 16-byte boundary, but tlsf_malloc() only guarantees an 8-byte alignment so a member declared inside a Yojimbo message with 16-byte alignment might end up at an 8-byte boundary.
This has a tiny cost of the occasional additional 8-bytes of waste per allocation, but in practice I've seen this to be within noise. Debugging an issue like this might be unobvious for non-senior engineers, so I think the cost is justified.