Fix Allocator's alignment problems. #469
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This reverts commit 9eccf67. Not actually necessary with USE_SYSTEM_ALLOCATION!
… TimeoutProtector as tightly as possible
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See #452.
Lib::Allocatorreturns insufficiently-aligned memory, which is undefined behaviour and will eventually bite us. It's also very complicated, which makes it hard to fix. Removing it altogether loses us more performance than we'd like.However, status-quo performance can be restored by strapping a very minimal small-object allocator to the front of the system allocator. This PR does exactly that. We also need to track heap memory, so we provide a very tiny global
operator newreplacement that counts allocations and directly forwards tomalloc/free.From a maintenance point of view, this removes the source of undefined behaviour, reduces the amount of platform-specific code, and reduces the amount of code overall. Vampire hackers no longer need to route allocations through our custom allocator unless there is a compelling performance reason to do so.