Does it support running wasm in go

At present, we support the running of wasm module in the mosn project (implemented in go language), and found that teavm also supports the generation of wasm files, and we hope that the wasm generated by java can also run in the go environment.

I wrote a demo to test the wasm file generated by teavm，found some functions that rely on teavm, but they will not be implemented in the host.

➜  wasm git:(master) ✗ wasm-objdump -x classes.wasm -j Import
classes.wasm:   file format wasm 0x1
Section Details:

Import[6]:
// user defined function
 - func[0] sig=2 <.hello> <- .hello

// These functions are not required to execute the wasm module in go
 - func[1] sig=1 <teavm.logString> <- teavm.logString
 - func[2] sig=1 <teavm.logInt> <- teavm.logInt
 - func[3] sig=5 <teavm.logOutOfMemory> <- teavm.logOutOfMemory
 - func[4] sig=1 <teavmHeapTrace.init> <- teavmHeapTrace.init
 - func[5] sig=14 <teavm.currentTimeMillis> <- teavm.currentTimeMillis

Similar to the export part, there are also functions that teavm depends on：

➜  wasm git:(master) ✗ wasm-objdump -x classes.wasm -j Export

classes.wasm:   file format wasm 0x1

Section Details:

Export[36]:
// user defined function
 - func[8] <thePurposeOfLife> -> "thePurposeOfLife"

// These functions are not required to execute the wasm module in go
 - func[37] <teavm_gc_collect> -> "teavm_gc_collect"
 - func[38] <teavm_gc_collectFull> -> "teavm_gc_collectFull"
 - func[45] <teavm_gc_fixHeap> -> "teavm_gc_fixHeap"
 - func[46] <teavm_gc_tryShrink> -> "teavm_gc_tryShrink"
 - func[107] <teavm_catchException> -> "teavm_catchException"
 - func[109] <teavm_throwNullPointerException> -> "teavm_throwNullPointerException"
 - func[110] <teavm_throwArrayIndexOutOfBoundsException> -> "teavm_throwArrayIndexOutOfBoundsException"
 - func[119] <teavm_processQueue> -> "teavm_processQueue"
 - func[120] <teavm_stopped> -> "teavm_stopped"
 - func[137] <teavm_allocateString> -> "teavm_allocateString"
 - func[138] <teavm_stringData> -> "teavm_stringData"
 - func[139] <teavm_allocateObjectArray> -> "teavm_allocateObjectArray"
 - func[140] <teavm_allocateStringArray> -> "teavm_allocateStringArray"
 - func[141] <teavm_allocateByteArray> -> "teavm_allocateByteArray"
 - func[142] <teavm_allocateShortArray> -> "teavm_allocateShortArray"
 - func[143] <teavm_allocateCharArray> -> "teavm_allocateCharArray"
 - func[144] <teavm_allocateIntArray> -> "teavm_allocateIntArray"
 - func[145] <teavm_allocateLongArray> -> "teavm_allocateLongArray"
 - func[146] <teavm_allocateFloatArray> -> "teavm_allocateFloatArray"
 - func[147] <teavm_allocateDoubleArray> -> "teavm_allocateDoubleArray"
 - func[148] <teavm_objectArrayData> -> "teavm_objectArrayData"
 - func[149] <teavm_byteArrayData> -> "teavm_byteArrayData"
 - func[150] <teavm_shortArrayData> -> "teavm_shortArrayData"
 - func[151] <teavm_charArrayData> -> "teavm_charArrayData"
 - func[152] <teavm_intArrayData> -> "teavm_intArrayData"
 - func[153] <teavm_longArrayData> -> "teavm_longArrayData"
 - func[154] <teavm_floatArrayData> -> "teavm_floatArrayData"
 - func[155] <teavm_doubleArrayData> -> "teavm_doubleArrayData"
 - func[156] <teavm_arrayLength> -> "teavm_arrayLength"
 - func[215] <teavm_javaHeapAddress> -> "teavm_javaHeapAddress"
 - func[216] <teavm_availableBytes> -> "teavm_availableBytes"
 - func[217] <teavm_regionsAddress> -> "teavm_regionsAddress"
 - func[218] <teavm_regionSize> -> "teavm_regionSize"

Question:

1. Wasm should be portable. Can dependencies on specific environments be disabled? Similar to the wasm generated by tinygo compilation, specify target=wasi, so that all dependencies on js will be removed.

Here is the wasm file (wasi specification) I compiled with go:

➜  wasm git:(fix_hijack_context_not_found) wasm-objdump -x bolt-go.wasm -j Import
bolt-go.wasm:   file format wasm 0x1
Section Details:

Import[5]:
// Functions generated by the compiler
 - func[0] sig=0 <fd_write> <- wasi_unstable.fd_write
 
//  User-defined host implementation functions
 - func[1] sig=1 <proxy_get_buffer_bytes> <- env.proxy_get_buffer_bytes
 - func[2] sig=2 <proxy_get_header_map_pairs> <- env.proxy_get_header_map_pairs
 - func[3] sig=1 <proxy_set_buffer_bytes> <- env.proxy_set_buffer_bytes
 - func[4] sig=2 <proxy_log> <- env.proxy_log

➜  wasm git:(fix_hijack_context_not_found) wasm-objdump -x bolt-go.wasm -j Export

bolt-go.wasm:   file format wasm 0x1

Section Details:

Export[28]:
// Functions generated by the compiler
 - memory[0] -> "memory"
 - func[71] <_start> -> "_start"

// //  User-defined wasm exported functions
 - func[176] <proxy_decode_buffer_bytes> -> "proxy_decode_buffer_bytes"

1. Go itself has its own gc capability, the wasm module written in java is executed in go, is gc processed by wasm itself? Or do not have gc capability?

[jcaesar]

I’d also like to run Java in such a strange way.

why?

I have added a plugin system to my existing application. I’ve based it on WebAssembly because

• WebAssembly is comparatively language and architecture agnostic - you can write a plugin for my app in C, Rust, Go, Python, …
• Easy to embed into an existing application (compared to e.g. Node or a JVM) - most WASM runtimes are designed to be used as a library
• The runtime I use allows for tricky things like having multiple isolated instances of the same module and limiting the CPU usage (both seem impossible with the non-strange way of Java running in OpenJDK)

So, I’d like to be able to support as many languages as possible, and supporting JVM languages would be a big plus in that direction.

Ultimately, this currently fails because I expect my plugins to provide me with pointers into their memory, and that memory should contain a CBOR buffer. I failed to achieve this, because Jackson et al. won’t compile (e.g. because UUID and ConcurrentHashMap are missing), and because getting a pointer to the content of a byte[] is currently not possible (apologies if I’ve missed an intrinsic I can use from inside/Java).

There are few functions that you should provide […] What’s the problem to write these functions for your environment?

I’ve attempted this and it indeed wasn’t difficult. But it also isn’t a very good solution, since these imports are internal interface that may change at any release, right? (Side note: This strategy is also used for Go, and showing the same weaknesses.)

Wasi does not work in the browser,

There are libraries/polyfills for that. Alternatively, implementing the three functions you need (fd_write for logString/logInt/LogOOM, random_get, clock_time_get) should also be rather trivial. The rest of the imports could be implemented in Java only(?), but that is a lot less trivial, and would increase binary size 😦.

Anyway, TeaVM generated WASM currently seems to need at least a little support from the outside system. Maybe that could change when WASM gets its own GC and exception support, but currently, I don’t think it’s possble for TeaVM to run entirely with what WASI provides.

So in summary: TeaVM is for running Java in the browser. I would be happy if it could be extended to a broader scope, but I don’t think it can (but not for the reasons previously mentioned here).

[jcaesar]

I see. TeaVM holds significantly more magic than I expected. I’m considerably more optimistic that I might be able to run Java in my plugin system. (I’m on vacation next week… 😉 So not too soon.)

Isn’t Class.getCanonicalName supported in latest versions?

It is. (And sorry, I just used the archetype from getting started without thinking. That still comes with 0.6.1 from central.) Now that I know that the current version has more support, I’ll try a few more libraries. Maybe one of them happens to be usable as is. (You’re right, testing data structures like ConcurrentHashMap is tricky. Maybe in this case, one could at least use fuzzing, since execution is deterministic. (If it actually is…?))

I’ll write a simple JSON parser in an hour. Do you need one?

You may leave that exercise to the reader. 😉