Fix memory leaks, make extension types more efficient #803
+261
−184
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
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.
I was baffled previously, because any time that
freewas called on a type from an extension, it would hang even when I knew it wasn't in use any longer, and hadn't been double free'd.After #737 was merged, I tried it again and noticed that it would no longer hang... but only for extensions that were staticly linked.
Then I realized that we are using a global allocator, that likely wasn't getting used in the shared library that is built separately that won't inherit from our global allocator in core, causing some symbol mismatch and the subsequent hanging on calls to
free.This PR adds the global allocator to extensions behind a feature flag in the macro that will prevent it from being used in
wasmand staticly linked environments where it would conflict with limbos normal global allocator. This allows us to properly free the memory from returning extension functions over FFI.This PR also changes the Extension type to a union field so we can store int + float values inline without boxing them.
any additional tips or thoughts anyone else has on improving this would be appreciated 👍