Conversation
|
Interesting idea! This should be more efficient since it lets sbrk increase the size only when actually necessary to accommodate the alignment. Looks like it increases code size somewhat - do you think it's worth it? I'm on the fence myself, since the extra overhead that this removes is only in special cases (like mimalloc) that allocate with very high alignment, and even then the extra space can be added to the previous region at least. |
That is the question I was pondering also, and I thought to let the CI answer how big the size regression would actually be. But it looks like the CI is currently failing on code size tests in main branch already, given that the other PR #20784 is already failing, so not sure what the real delta would be. Is there a PR yet to rebaseline the code size tests on main? |
I just landed b7924c4 |
|
Yeah, I am leaning as well that this is not worth it, so closing. |
This PR shows how we could avoid the pessimistic
size+alignmentrounding up when sbrk()ing to acquire an aligned allocation. A follow-up to #20704.