fermyon / teavm-wasi

Friendly fork of TeaVM with support for WASI and the WebAssembly Component Model

TeaVM-WASI

This repo contains a friendly fork of TeaVM, modified to support WASI and the WebAssembly Component Model proposal. We hope to eventually merge this work upstream if there is interest from the TeaVM maintainers. In the meantime, we have published the relevant packages to the Maven Central Repository under the groupId com.fermyon.

See here for an example of how to use the Maven plugin in your project.

See tests/wasi for an example command line app which exercises various WASI features.

The remainder of this document consists of the original TeaVM README.md.

TeaVM

See documentation at the project web site.

Useful links:

• Getting started
• Gallery
• Flavour source code repository
• Site source code repository
• Discussion on Google groups

Building TeaVM

Simply clone source code (git clone https://github.com/konsoletyper/teavm.git) and run maven build (mvn clean install). You can do things a little faster (mvn clean -DskipTests) or even a little more faster (mvn clean -DskipTests -Dteavm.build.all=false).

Preview builds

You may want to access new features and don't want to wait until stable release is published on Maven Central. In this case you can get latest development build from bintray. All you need is to put the following in your pom.xml:

  <repositories>
    <repository>
      <id>teavm-dev</id>
      <url>https://teavm.org/maven/repository</url>
    </repository>
  </repositories>
  <pluginRepositories>
    <pluginRepository>
      <id>teavm-dev</id>
      <url>https://teavm.org/maven/repository</url>
    </pluginRepository>
  </pluginRepositories>

IDEA plugin is also available in preview builds. You need to add corresponding repository manually to IDEA. Open Settings -> Plugins -> Browse repositories... -> Manage repositories..., click Add button and enter https://teavm.org/idea/dev/teavmRepository.xml. Then get back to Browse repositories and pick TeaVM plugin from list.

Embedding TeaVM

If you are not satisfied with Maven, you can embed TeaVM in your program or even create your own plugin for any build tool, like Ant or Gradle. The starting point for you may be org.teavm.tooling.TeaVMTool class from teavm-tooling artifact. You may want to go deeper and use org.teavm.vm.TeaVM from teavm-core artifact, learn how TeaVMTool initializes it. To learn how to use TeaVMTool class itself, find its usages across project source code. You most likely encounter Maven and IDEA plugins.

Please, notice that these APIs for embedding are still unstable and may change between versions.

WebAssembly

WebAssembly support is in experimental status. It may lack major features available in JavaScript backend. There's no documentation yet and you should do many things by hands (like embedding generated wasm file into your page, importing JavaScript objects, etc). Look at samples/benchmark module. You should first examine pom.xml file to learn how to build wasm file from Java. Then you may want to examine index-teavm.html and index-teavm.js to learn how to embed WebAssembly into your web page.

License

TeaVM is distributed under Apache License 2.0. TeaVM does not rely on OpenJDK or code or other (L)GPL code. TeaVM has its own reimplementation of Java class library, which is either implemented from scratch or based on non-(L)GPL projects:

• Apache Harmony (Apache 2.0)
• Joda-Time (Apache 2.0)
• jzlib (BSD style license)

If you want to contribute code to implementation of Java class library, please make sure it's no based on OpenJDK or other code licensed under (L)GPL.

Feedback

More information is available at the official site: https://teavm.org.

Ask your questions by email: [email protected]. Also you can report issues on a project's issue tracker.

teavm-wasi's Issues

Debug and fix WebAssembly test failures

Currently, many tests are failing for the WebAssembly target -- both when run via a browser and via wasmtime or wasmer.

Some of those tests are expected to fail (e.g. all the JSO tests, which only work for the JS target), so we should update the test runner to skip those for the WebAssembly target. The remaining tests will need to be debugged and fixed.

The end goal is to have all (relevant) tests passing and start running them as a CI job.

WASM GC Support

Will TeaVM-WASI be supporting WASM GC?

I'm trying to make a plugin system with Wasmtime and Kotlin. Then I found TeaVM-WASI from project wit-bindgen. In my scenario, the memory consumption and CPU resource consumption is critical, so I'm really excited to see wasm gc proposal is accepted. Can I just wait for TeaVM-WASI to give it a support or should I try something else?

Bigger heap for cabi_realloc to support component model

I was trying to make teavm-wasi with the component model using the preview2 wasi adapter and managed to make it work (only tried some very simple examples though) with a slightly customized adapter and wasm-tools.

The only problem seems to be that the native heap provided by cabi_realloc in the Memory.java is limited to 32k and the preview2 adapter tries allocating 64k for the adapter stack and 64k for its state (I might be wrong in that bein 2x64k, maybe it is just one - but definitely more than 32k).

Changing these two numbers:

• https://github.com/bytecodealliance/wasm-tools/blob/main/crates/wit-component/src/gc.rs#L13
• https://github.com/bytecodealliance/wasmtime/blob/main/crates/wasi-preview1-component-adapter/src/lib.rs#L2150

to 12k makes the whole thing work with wasmtime, component model enabled.

I tried to understand how the allocation in Memory.java works but I could not find all the bits of context I need to be sure about it.

So my question is - can we increase this 32k limitation to enable experimenting with teavm-wasi + component model?

Move WASI tests into main test suite

Currently, the WASI tests (under the tests/wasi directory) must be run manually using tests/wasi/test.sh. We should rewrite that test script as a JUnit test like the others so that it is run as part of the full test suite.

Emit a "producers" section

https://github.com/WebAssembly/tool-conventions/blob/main/ProducersSection.md

This would let us warn when preparing apps with known-broken toolchains.

Optionally generate DWARF debugging info for Wasm files

This would make debugging using e.g. wasmtime and gdb much more useful. To start with, just having line numbers would be a big win. Local variable info would be great, also.