Stream: wasmtime

Topic: Java Component Model Support

Ashanti Mutinta (Aug 21 2024 at 17:51):

So far I have only found teavm-wasi which hasnt been updated in 2 years . I was wondering if they are any other alternative modes for support for the java component model ? I guess maybe a lot of people are waiting for the GC standard? Link here https://github.com/fermyon/teavm-wasi

Joel Dice (Aug 21 2024 at 18:01):

This recent discussion might be helpful.

The TL;DR is that TeaVM uses its own class library, which is quite limited compared to e.g. OpenJDK's class library, and that means most non-trivial Maven packages aren't compatible with it. An ideal solution would reuse OpenJDK's class library; Bytecoder might be an option, and GraalVM native image support for Wasm could also be an option if it ever happens. Oracle seems to have no interest in Wasm, though, so the latter seems unlikely.

Ashanti Mutinta (Aug 27 2024 at 17:27):

Joel Dice said:

This recent discussion might be helpful.

The TL;DR is that TeaVM uses its own class library, which is quite limited compared to e.g. OpenJDK's class library, and that means most non-trivial Maven packages aren't compatible with it. An ideal solution would reuse OpenJDK's class library; Bytecoder might be an option, and GraalVM native image support for Wasm could also be an option if it ever happens. Oracle seems to have no interest in Wasm, though, so the latter seems unlikely.

Thought I replied to this but thank you for the response! I read through the discussion and it looks like bytecoder might be even more limited. I guess my vague question would be how "usable" is the current teavm-wasi? Is it enough to create reactors with the current wasi standards? I only ask cause I don't think it has been updated in a while

Joel Dice (Aug 27 2024 at 17:33):

I guess my vague question would be how "usable" is the current teavm-wasi? Is it enough to create reactors with the current wasi standards? I only ask cause I don't think it has been updated in a while

It hasn't been updated to support WIT resource types yet, so it can't be used to target WASIp2. I don't think it would be terribly difficult to update it to support resource types (and anything else that's missing), but someone would need to volunteer to do the work. I'd be happy to provide guidance, if needed. Also, the C# generator has full resource support, so that could be useful as a reference.

Pat Hickey (Aug 27 2024 at 17:33):

The best answer I can come up with, without expertise, is that CI runs cargo test for each language in the matrix including teavm-java currently, and that the following runtime tests exist:

[pat@Pats-MBP:tests/runtime]% find . | grep java
./smoke/wit_worlds_SmokeImpl.java
./records/wit_worlds_RecordsImpl.java
./records/wit_exports_test_records_TestImpl.java
./variants/wit_exports_test_variants_TestImpl.java
./variants/wit_worlds_VariantsImpl.java
./numbers/wit_exports_test_numbers_TestImpl.java
./numbers/wit_worlds_NumbersImpl.java
./lists/wit_worlds_ListsImpl.java
./lists/wit_exports_test_lists_TestImpl.java

Pat Hickey (Aug 27 2024 at 17:33):

which, as joel just pointed out, doesnt include anything involving resources.

Joel Dice (Aug 27 2024 at 17:37):

I should also point out that my TeaVM-WASI fork has fallen way behind the upstream TeaVM project, and Alexey (the upstream maintainer) has since implemented his own WASI support. So if you're serious about using TeaVM on WASI going forward, you might want to switch the wit-bindgen generator to use the upstream project instead of my fork. Not sure how much work that would be, but I'm guessing not trivial.

Ashanti Mutinta (Oct 31 2024 at 11:55):

Joel Dice said:

I should also point out that my TeaVM-WASI fork has fallen way behind the upstream TeaVM project, and Alexey (the upstream maintainer) has since implemented his own WASI support. So if you're serious about using TeaVM on WASI going forward, you might want to switch the wit-bindgen generator to use the upstream project instead of my fork. Not sure how much work that would be, but I'm guessing not trivial.

Came back to this to say I did a bit of hacking and implemented resources. Most of the code piggy backs of the csharp code and still needs a bit of testing but it generates and builds for now. I was wondering if you could tell me about RET_AREA if you don't mind. For wit bindgen is there an allocated memory space used to store return values? If that's true do you know how large it is and is there another area for complex objects? Thank you again!

Joel Dice (Oct 31 2024 at 13:38):

The Component Model does not yet support the core Wasm multi-value feature, so values which are too large to fit in a single (i32, i64, f32, or f64) stack value must be returned via a pointer to linear memory. When wit-bindgen generates code to call an imported function that requires return-via-memory, it allocates the memory needed before making the call, passing the pointer as an extra argument. The callee writes the result to that memory, and then the post-call code generated by wit-bindgen reads from that memory and then frees it (unless the return area is allocated on the shadow stack, as is the case for Rust and C).

For example, returning a tuple<u32, u32, u32> requires a return area 12 bytes in size, with 4 byte alignment. For more complex objects (e.g. variants with case payloads of various sizes), the canonical ABI defines the size and alignment requirements.

Ashanti Mutinta (Oct 31 2024 at 13:44):

Joel Dice said:

The Component Model does not yet support the core Wasm multi-value feature, so values which are too large to fit in a single (i32, i64, f32, or f64) stack value must be returned via a pointer to linear memory. When wit-bindgen generates code to call an imported function that requires return-via-memory, it allocates the memory needed before making the call, passing the pointer as an extra argument. The callee writes the result to that memory, and then the post-call code generated by wit-bindgen reads from that memory and then frees it (unless the return area is allocated on the shadow stack, as is the case for Rust and C).

For example, returning a tuple<u32, u32, u32> requires a return area 12 bytes in size, with 4 byte alignment. For more complex objects (e.g. variants with case payloads of various sizes), the canonical ABI defines the size and alignment requirements.

Makes a lot of sense it's essentially how complex objects were exchanged in preview one before wit. Very cool stuff! Thank you again! :smile:

Last updated: Dec 23 2024 at 14:03 UTC