Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update and use forked golem repos #1

Merged
merged 9 commits into from
Jun 14, 2024
Merged

Conversation

noise64
Copy link

@noise64 noise64 commented Jun 14, 2024

vados-cosmonic and others added 9 commits May 24, 2024 09:00
This commit adds the missing `jco types` subcommand to the README.

Signed-off-by: Victor Adossi <vadossi@cosmonic.com>
…odealliance#444)

* fix: don't overallocate string buffer while encoding into utf8

Recent dlmalloc-rs started validating that deallocation size is same as
the size that was allocated.
https://github.com/alexcrichton/dlmalloc-rs/blob/0.2.6/src/dlmalloc.rs#L1187

Since canonical abi string does not have "capacity" concept separate
from "length", we don't have a way to tell how much memory was
allocated to the buffer owner. So, canonical abi always assumes that
"length" is the same as "capacity" and deallocates the buffer with the
"length" size.

This means that if we overallocate the buffer and return the buffer with
a length less than the allocated size, dlmalloc-rs validation will fail.

This commit fixes the issue by lopping off the extra allocated space by
realloc with smaller size.

* fix: call realloc exactly once for string encoding

Previously, we would call realloc multiple times to grow the buffer and
shrink it back down to the correct size.
However, realloc provided by wasi-preview1-component-adapter is quite
restrictive:
* It can't always be called multiple times during a single imported
  function call.
* It does not accept non-null old pointers.

This commit changes the code to call realloc exactly once, which is
compatible with those restrictions. The use of temporary buffers with
`TextEncoder.encode` is less efficient than the previous `encodeInto`,
but it allows us to keep the allocator in the adapter simple.
We can optimize it after we will be able to get rid of the adapter or
decide to complicate the allocator in the adapter.
@noise64 noise64 marked this pull request as ready for review June 14, 2024 06:56
@noise64 noise64 requested a review from a team June 14, 2024 07:06
@noise64 noise64 merged commit 7c255cb into main Jun 14, 2024
16 checks passed
@noise64 noise64 deleted the update-and-use-forked-comp-js branch June 14, 2024 07:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants