JIT: replace golang-asm with a thread-safe one (from scratch) #233
Labels
Comments
|
In anyway, removing golang-asm dependency is good and well aligned with our main goal "zero dependency". |
|
FWIW I totally agree with this change |
|
please make it internal though :) I don't expect we need to support this api for third party use |
mathetake
added a commit
that referenced
this issue
Feb 22, 2022
This commit completes the baseline single pass JIT engine for arm64 target. The implementation passes 100% of specification tests and all the e2e tests that have been used for amd64. Notably, the engine is stable under high concurrency where multiple gorutines are holding stores and each of them has Wasm execution environment. One thing to note is that the assembler (golang-asm) is not goroutine-safe, so we have to take a lock on the assembler usage, therefore the compilation cannot scale to multiple CPU cores. This will be resolved once we build our homemade assembler in #233. resolves #187 Signed-off-by: Takeshi Yoneda <takeshi@tetrate.io>
This was referenced Mar 15, 2022
mathetake
added a commit
that referenced
this issue
Mar 17, 2022
This introduces Assembler interface to abstract away golang-asm behind it. Notably, new packages asm, asm/amd64 and asm/arm64 are added under internal/jit. Now golang-asm is only used in three files golang_asm.go, amd64/golang_asm.go and arm64/golang_asm.go where we implement amd64.Assembler and arm64.Assembler interface. part of #233 Signed-off-by: Takeshi Yoneda <takeshi@tetrate.io>
|
done with amd64.. now is the time to enjoy arm64! |
mathetake
added a commit
that referenced
this issue
Apr 12, 2022
This commit implements all the arm64 instruction encodings necessary for our JIT compiler and replaces the golang-asm assembler with our handmade assembler on arm64 platform. Notably, this allows us to do concurrent compilations. This closes #233 combined with #406. Signed-off-by: Takeshi Yoneda <takeshi@tetrate.io> Co-authored-by: Adrian Cole <adrian@tetrate.io>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In aarch64, golang-asm is not thread-safe, and the multi-goroutine engine test case actually fails if gorutine num > 1.
We could introduce a mutex in engine.Compile and lock the golang-asm usage, then the test passes, but it's not ideal.
Instead, we should replace golang-asm with a thread-safe, but there's not alternative out there.
That means we have to implement an assembler from scratch.
The text was updated successfully, but these errors were encountered: