Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Does it support running wasm in go

See original GitHub issue

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:

// 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:

// 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"


  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:

// 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:

// 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?

Issue Analytics

  • State:closed
  • Created 2 years ago
  • Comments:8 (4 by maintainers)

github_iconTop GitHub Comments

jcaesarcommented, Sep 17, 2021

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


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).

jcaesarcommented, Sep 17, 2021

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. 😉

Read more comments on GitHub >

github_iconTop Results From Across the Web

wasmerio/wasmer-go: 🕸️ WebAssembly runtime for Go
The major problem is that, whilst the Go compiler supports WebAssembly, it does not support WASI (WebAssembly System Interface). It generates an ABI...
Read more >
Golang WebAssembly - Binx
WebAssembly (WASM) is a portable binary instruction format which runs in the browser or on a server. It is designed with performance and ......
Read more >
WebAssembly with Golang by scratch | by Roman Romadin
This command will compile our go application into the main file. wasm (with wasm bytecode) is an executable module of a web assembly....
Read more >
WebAssembly - Working with Go - Tutorialspoint
Go has added support for WebAssembly from version 1.1 onwards. To test it first download, Go. Go to the golang site, which is...
Read more >
Using WebAssembly - TinyGo
You can call a JavaScript function from Go and call a Go function from ... The general steps required to run the WebAssembly...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found