Golang Support #381
Comments
|
It could be possible via a Go => LLVM => GraalVM bridge. There is this project https://go.googlesource.com/gollvm/ and this project https://github.com/go-llvm/llgo. The former looks more up-to-date. We will investigate what it takes. |
|
For what is worth I tried running lli with https://github.com/go-llvm/llgo and found that lli was failing to load some of the native libraries. I created a docker image that can be used for testing |
|
Yes, the relationship between the gollvm-created bitcode and the Go runtime library is somewhat special - FWIW, even llvm's own "lli" seems to be unable to handle it. |
|
If bitcode way is not working, well maybe not that perfect This is a student project done for Oracle for CMPS 116/117 at UCSC. Oracle’s Multilingual Engine (MLE) allows multiple languages to freely interoperate. This enables users to work with a language of their choosing when working with Oracle’s database products. The MLE relies upon the Truffle framework and Truffle languages to execute source code within the database process space. The goal of this project was to incorporate a subset of Go into Truffle’s suite of languages. |
Wouldn't going through truffle be better than LLVM in this case? Compiled Go programs contain a pretty big/multithreaded runtime (including a user-mode scheduler tightly integrated with the garbage collector and the built-in I/O event loop) that would need to run on top of the graal runtime. Even if suboptimal going the LLVM way may work at least in simple cases (footgun number one is likely going to be the presence of two GCs) but it would be pretty unusable for anything non-trivial involving cross-language interop (that would also depend on cgo, since there's no other supported way of doing interop with the standard go runtime). With a "trufflego" approach these issues wouldn't apply - although it would require signifcant work to get them right. (I'm gleefully glossing over the fact that going with truffle would require reimplementing a significant part of the runtime, as well as a Go interpreter -- and that therefore the amount of work is not even remotely comparable) |
|
golang is about release a compiler that can target |
|
I'm interested in this. |
|
Same here! |
|
We did get more requests for this feature recently. If anybody has some concrete example scenarios in mind for running Go on GraalVM; e.g., what would be the main expected benefits (interoperability? performance? tooling?), please share. |
We do have an example |
|
Vert.X has a language support based on Graal, which is es4x project |
@thomaswue it would lower the bar entering go applications in environments where the JVM is traditionally established, both by expertise, tooling and its operational foundation. think about companies that restrict their decision to use a language if it runs on the JVM. |
|
I think a killer use case is just to leverage libraries written in Java from Go and viceversa. The java ecosystem is very rich in the open source as well as within corporations. Allowing people to run software in go(or java) without having to re-implement well tested libraries would be key feature for graalvm. This is specially true given go is gaining grounds as a backend language. |
|
My use case, and the reason I opened the original issue, was so that I can use Go to write stored programs in MySQL, instead of javascript. |
|
Here is an experimental solution I was playing: https://gist.github.com/eginez/d69e3e1c4045eb692a274bd2bd5d31d6 |
|
How does this tre project compare to https://go.googlesource.com/gollvm/? I see that this was discussed further up. It seems still like this gollvm project could be a more solid way to create llvm bit code from go. |
|
agreed the above post is demonstrative only |
|
Being able to parse a terraform script in to JVM using it's original parser implementation would be a nice use case. |
|
How does support for Project Loom affect the viability of a truffle implementation for the Go runtime? |
|
It would surely make the implementation of go-routines much easier |
One scenario is that of compute-heavy applications; the go compiler is heavily focused on compilation speed, and for this reason it is extremely conservative w.r.t. which optimizations are performed (inlining is done extremely sparingly, very little devirtualization is supported, no LICM, no TCO, no autovectorization, very basic native arch detection, and especially no support for PGO1). As a result, compute-heavy operations (e.g. gzip encoding/decoding) when implemented in go and exposed with idiomatic interfaces end up being slower. GCC and llvmgo could help address some of these points, but IIRC they are missing higher-level go-specific knowledge about the memory allocator, GC and goroutine stacks, so they end up allocating more on the heap compared to the go compiler. At least on paper, a truffle-based implementation of go should fare significantly better here, especially for server-like workloads where there would be plenty of time to profile and specialize the compiled code. Another use-case is cgo, that currently is plagued by high overhead so it can only be used efficiently when the invoked native code has to do significant work. If the native code was instead compiled via sulong and the runtime implemented in truffle, the problem would potentially disappear altogether. Update (2023-01): Yet another use-case is when doing lots of disk I/O or other blocking syscalls (excluding network-I/O related ones, that -simplifying- are transparently transformed into their asynchronous/polling variants by the go runtime) the go runtime -again, simplifying- transparently spawns threads to perform them. With loom and io_uring a graal implementation could transparently transform all supported blocking syscalls into their io_uring equivalents, avoiding the need for spawning all these threads. Footnotes
|
At present, the wasm module is supported on the go project mosn, and we hope that the wasm compiled by java can also be executed (outside the js environment). We have implemented protocol extensions in the rpc, so we also hope that java developers can provide extension plugins. We noticed that wasm currently supports multiple language implementations：https://github.com/proxy-wasm/spec
In the java compiler, no examples of use in a non-web environment have been found so far. |
|
LLVM supports GCC's IR. Has anyone investigated the possibility of using gccgo as a bridge? |
|
The wasm backend of Go, does seem to be production ready now: |
|
And I found also a binding to LLVM, although it speaks about a 'system-installed' LLVM, and is at least hosted by the TinyGo project, so it may provide just bindings for this subset |
We have an SDK, with different codebases in different languages. Currently, we have to replicate the SDK into each language we support (support madness); I would like to have one SDK in one language, and use GraalVM to interop with the user code. Bindings are also a mess. This being said, also supporting haskell would be so useful. |
I did not try it for myself, and remember people saying it does run on Graal Sulong. The Haskell compiler has a native LLVM backend these days. |
|
You asked for concrete examples: I have some Go scripts (image processing) - in Go because I can't write C and Go is almost as performant AND it compiles fast. But Go doesn't have good visualization libraries, while e.g. Python and Javascript do (matplotlib and d3) |
|
Did you see the wasm and llvm compiler? It seems like an opportunity to run Go on Graal. |
Will Go be supported in the future?
The text was updated successfully, but these errors were encountered: