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 wasmer to 4.3 #2147

Merged
merged 7 commits into from
May 23, 2024
Merged

Update wasmer to 4.3 #2147

merged 7 commits into from
May 23, 2024

Conversation

chipshort
Copy link
Collaborator

closes #1628

Wasmer bumped their module version, so no need to bump our MODULE_SERIALIZATION_VERSION

Looks like the coverage job is running out of memory again.
@webmaster128 Can we bump that to a larger resource class?

The package_vm_windows job was also failing. I did a full cargo update to fix that (I couldn't easily figure out what package caused the linker problems. If you have tips, please tell me), followed by downgrading wat to 1.207.0 (instead of 1.208.1) to avoid their Rust 1.76 requirement.

@webmaster128
Copy link
Member

@webmaster128 Can we bump that to a larger resource class?

Let's try to reduce the parallelization first. Cargo probably gets a value of 32 or 64 when asking the system for CPU count. For one other job we already have this:

    environment:
      # Limit the number of parallel jobs to avoid OOM crashes during doc testing
      RUST_TEST_THREADS: 8

@aumetra
Copy link
Member

aumetra commented May 22, 2024

The package_vm_windows job was also failing. I did a full cargo update to fix that

Thought for a second that it might have been the cache, but can't be because the lockfile changed during the Wasmer upgrade.. weird.

@aumetra
Copy link
Member

aumetra commented May 22, 2024

Wanna try to plug in an alternative linker since this seems to die on the ld invocation? mold claims to have a lower RSS than gold and lld

@aumetra
Copy link
Member

aumetra commented May 22, 2024

Otherwise I'd even say let's go for -C instrument-coverage instead of gcov. Personally I had issues with OOM using tarpaulin and even gcov (IIRC) but never with cargo-llvm-cov

@chipshort
Copy link
Collaborator Author

Otherwise I'd even say let's go for -C instrument-coverage instead of gcov

But isn't that what is failing here? The compilation with -C instrument-coverage?
I think a different linker is worth a try.

@aumetra
Copy link
Member

aumetra commented May 22, 2024

But isn't that what is failing here? The compilation with -C instrument-coverage?

NVM yeah, you're right. I was mixing up grcov and gcov lol. Would be nice if they came up with more distinct names next time

@chipshort
Copy link
Collaborator Author

Had to switch the coverage job to alpine 3.19 in order to get a somewhat recent mold version, but it seems to help with the memory usage

@webmaster128
Copy link
Member

I don't have strong opinions which coverage tool to use. But if we change it, let's please do that in a separate PR

@aumetra
Copy link
Member

aumetra commented May 22, 2024

Yep, definitely. But it seems like using a different linker did the trick already, so this looks good to go

@chipshort chipshort marked this pull request as ready for review May 23, 2024 07:31
@chipshort chipshort merged commit 37f1e95 into main May 23, 2024
31 checks passed
@chipshort chipshort deleted the wasmer-update branch May 23, 2024 07:33
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.

ARM Compiler Panic due to ImpossibleRelocation error (aka. Upgrade to Wasmer 4.3)
3 participants