Begin the job of converting the linker's "gentext" phase over to use
loader APIs. This patch includes most architectures except for s390x
and PPC (these will be added in subsequent patches, since they require
a couple of loader changes first).
Change-Id: Ic7f55c207dcdbbba657330ef007a72ff7c837416
Reviewed-on: https://go-review.googlesource.com/c/go/+/227017
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Also a similar 'elapsed' function and its usages were deleted.
Fixes#19865.
Change-Id: Ib125365e69cf2eda60de64fa74290c8c7d1fd65a
Reviewed-on: https://go-review.googlesource.com/c/go/+/171730
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
While building a simple hello world binary, there are total 858277 calls
to writeUleb during the assembler phase out of which 836625 (97%) are less than 7 bits.
Using a simple micro-benchmark like this:
func BenchmarkUleb(b *testing.B) {
var buf bytes.Buffer
for i := 0; i < b.N; i++ {
writeUleb128(&buf, 42)
buf.Reset()
}
}
We get the following results with the fast path enabled.
name old time/op new time/op delta
Uleb-4 8.45ns ± 2% 7.51ns ± 2% -11.16% (p=0.000 n=10+10)
Applying the time taken to the number of calls, we get roughly 6% improvement
in total time taken for writeUleb128.
We also apply the change to the function in linker to make it consistent.
Change-Id: I9fe8c41df1209f5f3aa7d8bd0181f1b0e536ceb5
Reviewed-on: https://go-review.googlesource.com/c/go/+/201177
Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CL 170950 had a regression that makes the compiler produce
an invalid wasm binary if the data section is too large.
Loading such a binary gives the following error:
"LinkError: WebAssembly.instantiate(): data segment is out of bounds"
This change fixes the issue by ensuring that the minimum size of the
linear memory is larger than the end of the data section.
Fixes#34395.
Change-Id: I0c8629de7ffd0d85895ad31bf8c9d45fef197a57
Reviewed-on: https://go-review.googlesource.com/c/go/+/199358
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change adds an optional "producer" section that reports the source
language and compiler version. See
https://github.com/WebAssembly/tool-conventions/blob/master/ProducersSection.md.
It also removes the now redundant "go.version" section.
Fixes#33295.
Change-Id: Ib4c80528728caf9e524fbd3f26822cbbc8b05a75
Reviewed-on: https://go-review.googlesource.com/c/go/+/196804
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Agniva De Sarker <agniva.quicksilver@gmail.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Most changes are removing redundant declaration of type when direct
instantiating value of map or slice, e.g. []T{T{}} become []T{{}}.
Small changes are removing the high order of subslice if its value
is the length of slice itself, e.g. T[:len(T)] become T[:].
The following file is excluded due to incompatibility with go1.4,
- src/cmd/compile/internal/gc/ssa.go
Change-Id: Id3abb09401795ce1e6da591a89749cba8502fb26
Reviewed-on: https://go-review.googlesource.com/c/go/+/166437
Run-TryBot: Dave Cheney <dave@cheney.net>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Use mmap for writing most of the output file content,
specifically, the sections and segments. After layout, we
already know the sizes and file offsets for the sections and
segments. So we can just write the bytes by copying to a mmap'd
backing store.
The writing of the output file is split into two parts. The first
part writes the sections and segments to the mmap'd region. The
second part writes some extra content, for which we don't know
the size, so we use direct file IO.
This is in preparation for mmap'ing input files read-only.
Change-Id: I9f3b4616a9f96bfd5c940d74c50aacd6d330f7d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/170738
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
WebAssembly's memory is contiguous. Allocating memory at a high address
also allocates all memory up to that address. This change reduces
the initial memory allocated on wasm from 1GB to 16MB by using multiple
heap arenas and reducing the size of a heap arena.
Fixes#27462.
Change-Id: Ic941e6edcadd411e65a14cb2f9fd6c8eae02fc7a
Reviewed-on: https://go-review.googlesource.com/c/go/+/170950
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Some WebAssembly runtimes (e.g. Node.js) fail to load a wasm binary if
it has more than 100000 data segments. Do not skip zero regions any more
if the limit was reached.
Change-Id: I14c4c2aba142d1d2b887bce6d03b8c1c1746c5ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/168884
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This change optimizes the data section in the wasm binary by
omitting blocks of zeroes and instead emitting data segments
with offsets skipping the zeroes.
This optimization is inspired by the memory-packing pass of the
wasm-opt tool and reduces the wasm binary size of "hello world" by 14%.
Change-Id: Iba3043df05bf6aab4745c5f8015c0337fc218aff
Reviewed-on: https://go-review.googlesource.com/c/go/+/167801
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
With this change, callbacks returned by syscall/js.NewCallback
get executed synchronously. This is necessary for the APIs of
many JavaScript libraries.
A callback triggered during a call from Go to JavaScript gets executed
on the same goroutine. A callback triggered by JavaScript's event loop
gets executed on an extra goroutine.
Fixes#26045Fixes#27441
Change-Id: I591b9e85ab851cef0c746c18eba95fb02ea9e85b
Reviewed-on: https://go-review.googlesource.com/c/142004
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The interface between the wasm binary and wasm_exec.js is experimental
and likely to change in the future. Still, there are some early adopters
who experiment with non-web wasm runtimes. They can't use wasm_exec.js
and have to provide their own equivalent. Adding the Go version as a
custom wasm sections allows for them to support a stable Go version and
the latest devel at the same time.
Change-Id: I6d377bb0a0c33cb80e86dd15a34ddc9a70680227
Reviewed-on: https://go-review.googlesource.com/127597
Run-TryBot: Richard Musiol <neelance@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Add Go buildids into a custom wasm section ("go.buildid", arbitrarily)
early in the wasm module, right after the magic & version.
Fixes#25910
Change-Id: If3f7cb267bf8c7beb6fa8d8b7a4829419720bbd8
Reviewed-on: https://go-review.googlesource.com/119175
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Chrome and Node.js were not showing the names of WebAssembly
functions any more. This was due to the name section containing
names also for import functions, which is redundant.
Change-Id: I2f2b2d0b5bd7a59b34f108d2fd7b6ba2eb26f9c9
Reviewed-on: https://go-review.googlesource.com/118976
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This commit adds support for JavaScript callbacks back into
WebAssembly. This is experimental API, just like the rest of the
syscall/js package. The time package now also uses this mechanism
to properly support timers without resorting to a busy loop.
JavaScript code can call into the same entry point multiple times.
The new RUN register is used to keep track of the program's
run state. Possible values are: starting, running, paused and exited.
If no goroutine is ready any more, the scheduler can put the
program into the "paused" state and the WebAssembly code will
stop running. When a callback occurs, the JavaScript code puts
the callback data into a queue and then calls into WebAssembly
to allow the Go code to continue running.
Updates #18892
Updates #25506
Change-Id: Ib8701cfa0536d10d69bd541c85b0e2a754eb54fb
Reviewed-on: https://go-review.googlesource.com/114197
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Each URL was manually verified to ensure it did not serve up incorrect
content.
Change-Id: I4dc846227af95a73ee9a3074d0c379ff0fa955df
Reviewed-on: https://go-review.googlesource.com/115798
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
