chore: Remove the experimental SetFinalizer allocator #4737
+16
−181
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
c5fb12e to
5596aaa
Compare
nathanielc
approved these changes
May 11, 2022
Every time we allocate an arrow array we check that we do not exceed the maximum memory limit. Since this limit check is before the allocation step (and garbage collection) we inevitably end up in a situation where the limit gets exceeded before the garbage collector has a chance to run. Worse, go's garbage collector is highly incremental so even when it does run, we can still end up allocating more than we collect, thereby exceeding the limit. The only way I can see this allocator working is if the limit is so far above the amount of memory actually being in use, which would let the garbage collector keep up. However in that case the memory limit wouldn't really relate to how much memory were actually in use making it rather arbitrary. Closes #4486
5596aaa to
3a57cc8
Compare
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.
Every time we allocate an arrow array we check that we do not exceed the maximum memory limit.
Since this limit check is before the allocation step (and garbage collection) we inevitably
end up in a situation where the limit gets exceeded before the garbage collector has a chance
to run. Worse, go's garbage collector is highly incremental so even when it does run, we can
still end up allocating more than we collect, thereby exceeding the limit.
The only way I can see this allocator working is if the limit is so far above the amount of
memory actually being in use, which would let the garbage collector keep up. However in that case
the memory limit wouldn't really relate to how much memory were actually in use making it rather arbitrary.
Closes #4486