Alexander Girke
05/13/2023, 7:07 AM@JsName(name = "exports#string-error")
fails with error Name contains illegal chars that can't appear in JavaScript identifier
-> however, look like such method name should be valid e.g. in WIT definitions: https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md#identifiers
• Writing to Custom Section of WASM file -> looks like this is needed for component model. TeaVM offers an @CustomSection
annotation to allow passing data to WASM file (see https://github.com/konsoletyper/teavm/blob/9f349385ec29ced175233cb0c3a247b87719cee[…]main/java/org/teavm/backend/wasm/render/WasmBinaryRenderer.java) is there something similar planned for Kotlin already?
• allocated memory is always 8-byte aligned (https://github.com/JetBrains/kotlin/blob/917f64c8939878821f1bad9b6776238d4f09b675/[…]ibraries/stdlib/wasm/src/kotlin/wasm/unsafe/MemoryAllocation.kt). I see the comment that 8 is the maximum alignment in component model abi. Just for my understanding, does this mean, supporting other alignments is just a matter of optimization? -> to me it seems that other alignments should be possible as well, e.g. at least TeaVM implementation is able to handle that https://github.com/bytecodealliance/wit-bindgen/blob/main/crates/teavm-java/src/lib.rs#L2063.
• In general, the ScopedMemoryAllocator does not exactly fit to the code generated by wit-bindgen, as it doesn’t allow to free memory in a callback - which seems to be the way the component model handles de-allocation (via a generated method prefixed with cabi_post_*
) - any chance that there will be an implementation of MemoryAllocator that allows that usage pattern?
I think I’ll be able to share the current state soon to better illustrate the shortcomings.Svyatoslav Kuzmich [JB]
05/15/2023, 5:50 AMAnnotationfails with error@JsName(name = "exports#string-error")
Name contains illegal chars that can't appear in JavaScript identifier
@WasmImport("module", "name")
should be used for WIT instead, it doesn’t have such restrictions. We’ll also need to implement corresponding @WasmExport
Writing to Custom Section of WASM fileI didn’t know about this, thanks. It looks like we need this indeed, but we don’t have it yet.
allocated memory is always 8-byte aligned. … does this mean, supporting other alignments is just a matter of optimization?Yes.
ScopedMemoryAllocator does not exactly fit to the code generated by wit-bindgenIndeed. We need to implement realloc function export.
Alexander Girke
05/15/2023, 8:29 PMAnnotationSure, for import I was usingshould be used for WIT instead, it doesn’t have such restrictions. We’ll also need to implement corresponding@WasmImport("module", "name")
@WasmExport
@WasmImport
, but since there currently is no @WasmExport
I’m using @ExperimentalJsExport
together with @JsName
. How much would it take to remove the restriction for @JsName
in the WASM context as a shortcut? Probably implemented faster than introducing the @WasmExport
annotation, right?
Regarding the TODOs on Kotlin-side (@WasmExport
, Custom Section & realloc function): should I file an issue on Youtrack or will you create an internal ticket for that?sdeleuze
05/16/2023, 6:50 PMAlexander Girke
05/17/2023, 8:59 AM@WasmExport/@JsName
restrictions at least) + wasmparser
crate not supporting GC proposal code. The latter looks like it’s going to be fixed very soon with https://github.com/bytecodealliance/wasm-tools/pull/1022.
Regarding kowasm, I’d be happy to contribute if you see anything that I can add there.sdeleuze
05/17/2023, 9:18 AMAlexander Girke
05/20/2023, 10:49 AM@JsName
export names), but doesn’t run yet due to missing implementation of GC proposal in wasmparser
crate (Ivan Mikushin said that he thinks he can complete that in ~1month) and maybe others. Also, memory allocation & de-allocation will probably not work as expected. I tried to stick as close to the TeaVM Java implementation as possible to minimize maintenance later, but of course I don’t know yet if the generated code would actually run correctly.
If you want to have a look at generated test code, run cargo test
in the repository’s root directory & view the files at target/runtime-tests/{test-case}/kotlin-{test-case}
- currently, {test-case}
equals one of smoke
(already free of any compile error because there are no exports), lists
, numbers
, records
or variants
. Please let me know if you see any obvious issues.