feat: wasm64 tech validation

[lwshang]

Description

This draft PR serves as an experimental validation to assess whether the proposed design changes to the wasm64 system API change can seamlessly integrate into Rust CDK.

The system API text and the bindgen

This part is mainly about the ic0 crate.

• ic0.txt: The notable change in the system API text is the replacement of i32 pointers with I ∈ {i32, i64}.
• ic0build.rs: this bindings generation script was modified accordingly. It replaces the I with isize.
• ic.rs: This is the generated Rust unsafe binding. The conditional compilation now uses#[cfg(target_family = "wasm")] which will work with all wasm32-* and wasm64-* targets.

Handle the env: i32 parameter

In the existing wasm32-only scenario, the env: i32 parameters in call_new() and call_on_cleanup() are used as raw pointers (32-bit).

When it comes to wasm64, env: i32 can no longer be used as pointers (64-bit) anymore. We have to introduce an extra indirection which maps from 32-bit integers to 64-bit pointers.

slotmap fork

I forked the slotmap crate, halve the bit-width of KeyData fields (from u32 to u16), so that the key can be lossless converted to/from u32. This introduces a limitation wherein there cannot be more than $2^{16}-1 = 65525$ open calls. The number can be expanded by doing more modification to the slotmap crate. But the limitation itself is inevitable.

The indirection

new_key_type! { struct StateId;}

thread_local! {
    // The inner map is a mapping from StateId to the pointer of Arc<RwLock<CallFutureState<T>>>
    static STATES: RefCell<SlotMap<StateId, usize>> = RefCell::default();
}

Test

Given that the replica hasn't yet adopted wasm64 support, I continue to utilize the wasm32 target to verify the functionality of the slotmap indirection.

Now that all the existing tests pass, it proves the functionality.

Future

The following questions remain open for future exploration:

• Whether there is memory leak.
• Measure the overhead from the indirection.