Use DataView in bindings generation #2599
Merged
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.
Given the results of this simple experiment, instead of using short-lived views when accessing memory to work around a possibly detached buffer after a
memory.grow
, this PR changes memory accesses to utilize a cachedDataView
(see also), where a try/catch can be and now is used to detect a detached buffer.There is more that can be done here, like keeping track of where memory might actually grow, and if it's guaranteed to never grow in between two calls of the respective
__get/setXY
helpers access theDataView
directly in subsequent calls. So far this is done where trivial, e.g. in some__lift/lowerXY
helpers, but not yet in__lift/lowerRecord
where it's a bit unclear whether the additional complexity would actually be worth it.