Use wasm-gc based call adaptor if available#5310
Merged
hoodmane merged 11 commits intopyodide:mainfrom Jan 13, 2025
Merged
Conversation
I figured out a way to remove the super inefficient `calculate_wasm_func_nargs_fallback` and replace it with wasm-gc code. This should perform much better. The cpython patch message says: Part of the ongoing quest to support JSPI. The JSPI spec removed its dependence on JS type reflection, and now the plan is for runtimes to ship JSPI while keeping type reflection in stage 3. So we need an alternative way to count the number of parameters of a function. It is possible to count them by repeatedly trying to instantiate a webassembly module with the function as an import of a different type signature. But this is pretty inefficient. Since WebAssembly gc is now stage 4, there is a new option. WebAssembly gc added the `ref.test` instruction which can ask if a funcref has a given type. It's a bit difficult to apply because even our usual assembler the wasm binary toolkit doesn't support this instruction yet. But all JS engines that support JSPI support it. We just have to do some manual work to produce the binary. This code also has to be written carefully to interact properly with memory snapshots. Importantly, no JS initialization code can be called from the C initialization code. For this reason, we make a C function pointer to fill from JS and fill it in a preRun function.
ryanking13
reviewed
Jan 9, 2025
Comment on lines
185
to
190
| + const code = new Uint8Array([ | ||
| + 0x00, 0x61, 0x73, 0x6d, // \0asm magic number | ||
| + 0x01, 0x00, 0x00, 0x00, // version 1 | ||
| + 0x01, 0x23, // Type section, body is 0x23 bytes | ||
| + 0x06, // 6 entries | ||
| + 0x60, 0x00, 0x01, 0x7f, // (type $type0 (func (param) (result i32))) |
Member
Author
There was a problem hiding this comment.
Well you can see the wat above. The problem is that the wasm binary toolkit doesn't know how to handle ref.test $type4. Probably I should make a wasm binary toolkit PR to add support for this, but we'll see if I get around to it.
Member
Author
|
Upstream PR was merged so I'll go ahead and merge this too. |
hoodmane
added a commit
to hoodmane/pyodide
that referenced
this pull request
Jan 13, 2025
I figured out a way to remove the super inefficient `calculate_wasm_func_nargs_fallback` and replace it with wasm-gc code. This should perform much better. The cpython patch message says: Part of the ongoing quest to support JSPI. The JSPI spec removed its dependence on JS type reflection, and now the plan is for runtimes to ship JSPI while keeping type reflection in stage 3. So we need an alternative way to count the number of parameters of a function. It is possible to count them by repeatedly trying to instantiate a webassembly module with the function as an import of a different type signature. But this is pretty inefficient. Since WebAssembly gc is now stage 4, there is a new option. WebAssembly gc added the `ref.test` instruction which can ask if a funcref has a given type. It's a bit difficult to apply because even our usual assembler the wasm binary toolkit doesn't support this instruction yet. But all JS engines that support JSPI support it. We just have to do some manual work to produce the binary. This code also has to be written carefully to interact properly with memory snapshots. Importantly, no JS initialization code can be called from the C initialization code. For this reason, we make a C function pointer to fill from JS and fill it in a preRun function. Upstream PR: python/cpython#128628
Member
|
Thanks! |
This file contains hidden or 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
2 participants
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 figured out a way to remove the super inefficient
calculate_wasm_func_nargs_fallbackand replace it with wasm-gc code. This should perform much better. The cpython patch message says:Part of the ongoing quest to support JSPI. The JSPI spec removed its dependence on JS type reflection, and now the plan is for runtimes to ship JSPI while keeping type reflection in stage 3. So we need an alternative way to count the number of parameters of a function. It is possible to count them by repeatedly trying to instantiate a webassembly module with the function as an import of a different type signature. But this is pretty inefficient.
Since WebAssembly gc is now stage 4, there is a new option. WebAssembly gc added the
ref.testinstruction which can ask if a funcref has a given type. It's a bit difficult to apply because even our usual assembler the wasm binary toolkit doesn't support this instruction yet. But all JS engines that support JSPI support it. We just have to do some manual work to produce the binary.This code also has to be written carefully to interact properly with memory snapshots. Importantly, no JS initialization code can be called from the C initialization code. For this reason, we make a C function pointer to fill from JS and fill it in a preRun function.
Upstream PR:
python/cpython#128628