13 Commits

Author SHA1 Message Date
Johan Brandhorst-Satzkorn
be50055eef runtime: add remaining wasip1 files
Implements OS interactions and memory management.

For #58141

Co-authored-by: Richard Musiol <neelance@gmail.com>
Co-authored-by: Achille Roussel <achille.roussel@gmail.com>
Co-authored-by: Julien Fabre <ju.pryz@gmail.com>
Co-authored-by: Evan Phoenix <evan@phx.io>
Change-Id: I876e7b033090c2fe2d76d2535bb63d52efa36185
Reviewed-on: https://go-review.googlesource.com/c/go/+/479618
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
2023-04-06 17:48:24 +00:00
Achille Roussel
dac514ea37 runtime: reuse freed memory blocks on wasm
When compiling Go programs to WebAssembly, the memory allocation
strategy was neither releasing memory to the OS nor reusing blocks freed
by calls to runtime.sysFreeOS.

This CL unifies the plan9 and wasm memory management strategy
since both platforms use a linear memory space and do not have a
mechanism for returning memory blocks to the OS.

Fixes #59061

Change-Id: I282ba93c0fe1a0961a31c0825b2a7e0478b8713d
GitHub-Last-Rev: 1c485be4fb798679fde7db148392de558a6fa97c
GitHub-Pull-Request: golang/go#59065
Reviewed-on: https://go-review.googlesource.com/c/go/+/476717
Reviewed-by: Julien Fabre <ju.pryz@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Evan Phoenix <evan@phx.io>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
2023-03-21 02:45:06 +00:00
Evan Phoenix
02411bcd7c all: implement wasmimport directive
Go programs can now use the //go:wasmimport module_name function_name
directive to import functions from the WebAssembly runtime.

For now, the directive is restricted to the runtime and syscall/js
packages.

* Derived from CL 350737
* Original work modified to work with changes to the IR conversion code.
* Modification of CL 350737 changes to fully exist in Unified IR path (emp)
* Original work modified to work with changes to the ABI configuration code.
* Fixes #38248

Co-authored-by: Vedant Roy <vroy101@gmail.com>
Co-authored-by: Richard Musiol <mail@richard-musiol.de>
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Change-Id: I740719735d91c306ac718a435a78e1ee9686bc16
Reviewed-on: https://go-review.googlesource.com/c/go/+/463018
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
2023-03-02 05:28:55 +00:00
Russ Cox
9839668b56 all: separate doc comment from //go: directives
A future change to gofmt will rewrite

	// Doc comment.
	//go:foo

to

	// Doc comment.
	//
	//go:foo

Apply that change preemptively to all comments (not necessarily just doc comments).

For #51082.

Change-Id: Iffe0285418d1e79d34526af3520b415a12203ca9
Reviewed-on: https://go-review.googlesource.com/c/go/+/384260
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
2022-04-05 17:54:15 +00:00
Michael Anthony Knyszek
f990b0f1e8 runtime: add wrappers for sys* functions and consolidate docs
This change lifts all non-platform-specific code out of sys* functions
for each platform up into wrappers, and moves documentation about the OS
virtual memory abstraction layer from malloc.go to mem.go, which
contains those wrappers.

Change-Id: Ie803e4447403eaafc508b34b53a1a47d6cee9388
Reviewed-on: https://go-review.googlesource.com/c/go/+/393398
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
2022-03-31 20:02:55 +00:00
Russ Cox
f229e7031a all: go fix -fix=buildtag std cmd (except for bootstrap deps, vendor)
When these packages are released as part of Go 1.18,
Go 1.16 will no longer be supported, so we can remove
the +build tags in these files.

Ran go fix -fix=buildtag std cmd and then reverted the bootstrapDirs
as defined in src/cmd/dist/buildtool.go, which need to continue
to build with Go 1.4 for now.

Also reverted src/vendor and src/cmd/vendor, which will need
to be updated in their own repos first.

Manual changes in runtime/pprof/mprof_test.go to adjust line numbers.

For #41184.

Change-Id: Ic0f93f7091295b6abc76ed5cd6e6746e1280861e
Reviewed-on: https://go-review.googlesource.com/c/go/+/344955
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
2021-10-28 18:17:57 +00:00
Russ Cox
d4b2638234 all: go fmt std cmd (but revert vendor)
Make all our package sources use Go 1.17 gofmt format
(adding //go:build lines).

Part of //go:build change (#41184).
See https://golang.org/design/draft-gobuild

Change-Id: Ia0534360e4957e58cd9a18429c39d0e32a6addb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/294430
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
2021-02-20 03:54:50 +00:00
Michael Anthony Knyszek
8ebc58452a runtime: delineate which memstats are system stats with a type
This change modifies the type of several mstats fields to be a new type:
sysMemStat. This type has the same structure as the fields used to have.

The purpose of this change is to make it very clear which stats may be
used in various functions for accounting (usually the platform-specific
sys* functions, but there are others). Currently there's an implicit
understanding that the *uint64 value passed to these functions is some
kind of statistic whose value is atomically managed. This understanding
isn't inherently problematic, but we're about to change how some stats
(which currently use mSysStatInc and mSysStatDec) work, so we want to
make it very clear what the various requirements are around "sysStat".

This change also removes mSysStatInc and mSysStatDec in favor of a
method on sysMemStat. Note that those two functions were originally
written the way they were because atomic 64-bit adds required a valid G
on ARM, but this hasn't been the case for a very long time (since
golang.org/cl/14204, but even before then it wasn't clear if mutexes
required a valid G anymore). Today we implement 64-bit adds on ARM with
a spinlock table.

Change-Id: I4e9b37cf14afc2ae20cf736e874eb0064af086d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/246971
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
2020-10-26 18:09:41 +00:00
Michael Anthony Knyszek
763d3ac75c runtime: make sysReserve return page-aligned memory on js-wasm
This change ensures js-wasm returns page-aligned memory. While today
its lack of alignment doesn't cause problems, this is an invariant of
sysAlloc which is documented in HACKING.md but isn't upheld by js-wasm.

Any code that calls sysAlloc directly for small structures expects a
certain alignment (e.g. debuglog, tracebufs) but this is not maintained
by js-wasm's sysAlloc.

Where sysReserve comes into play is that sysAlloc is implemented in
terms of sysReserve on js-wasm. Also, the documentation of sysReserve
says that the returned memory is "OS-aligned" which on most platforms
means page-aligned, but the "OS-alignment" on js-wasm is effectively 1,
which doesn't seem right either.

The expected impact of this change is increased memory use on wasm,
since there's no way to decommit memory, and any small structures
allocated with sysAlloc won't be packed quite as tightly. However, any
memory increase should be minimal. Most calls to sysReserve and sysAlloc
already aligned their request to physPageSize before calling it; there
are only a few circumstances where this is not true, and they involve
allocating an amount of memory returned by unsafe.Sizeof where it's
actually quite important that we get the alignment right.

Updates #35112.

Change-Id: I9ca171e507ff3bd186326ccf611b35b9ebea1bfe
Reviewed-on: https://go-review.googlesource.com/c/go/+/205277
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Richard Musiol <neelance@gmail.com>
2019-11-07 17:45:27 +00:00
Agniva De Sarker
07f0460737 runtime,syscall/js: reuse wasm memory DataView
Currently, every call to mem() incurs a new DataView object. This was necessary
because the wasm linear memory could grow at any time.

Now, whenever the memory grows, we make a call to the front-end. This allows us to
reuse the existing DataView object and create a new one only when the memory actually grows.

This gives us a boost in performance during DOM operations, while incurring an extra
trip to front-end when memory grows. However, since the GrowMemory calls are meant to decrease
over the runtime of an application, this is a good tradeoff in the long run.

The benchmarks have been tested inside a browser (Google Chrome 75.0.3770.90 (Official Build) (64-bit)).
It is hard to get stable nos. for DOM operations since the jumps make the timing very unreliable.
But overall, it shows a clear gain.

name  old time/op  new time/op  delta
DOM    135µs ±26%    84µs ±10%  -37.22%  (p=0.000 n=10+9)

Go1 benchmarks do not show any noticeable degradation:
name                   old time/op    new time/op    delta
BinaryTree17              22.5s ± 0%     22.5s ± 0%     ~     (p=0.743 n=8+9)
Fannkuch11                15.1s ± 0%     15.1s ± 0%   +0.17%  (p=0.000 n=9+9)
FmtFprintfEmpty           324ns ± 1%     303ns ± 0%   -6.64%  (p=0.000 n=9+10)
FmtFprintfString          535ns ± 1%     515ns ± 0%   -3.85%  (p=0.000 n=10+10)
FmtFprintfInt             609ns ± 0%     589ns ± 0%   -3.28%  (p=0.000 n=10+10)
FmtFprintfIntInt          938ns ± 0%     920ns ± 0%   -1.92%  (p=0.000 n=9+10)
FmtFprintfPrefixedInt     950ns ± 0%     924ns ± 0%   -2.72%  (p=0.000 n=10+9)
FmtFprintfFloat          1.41µs ± 1%    1.43µs ± 0%   +1.01%  (p=0.000 n=10+10)
FmtManyArgs              3.66µs ± 1%    3.46µs ± 0%   -5.43%  (p=0.000 n=9+10)
GobDecode                38.8ms ± 1%    37.8ms ± 0%   -2.50%  (p=0.000 n=10+8)
GobEncode                26.3ms ± 1%    26.3ms ± 0%     ~     (p=0.853 n=10+10)
Gzip                      1.16s ± 1%     1.16s ± 0%   -0.37%  (p=0.008 n=10+9)
Gunzip                    210ms ± 0%     208ms ± 1%   -1.01%  (p=0.000 n=10+10)
JSONEncode               48.0ms ± 0%    48.1ms ± 1%   +0.29%  (p=0.019 n=9+9)
JSONDecode                348ms ± 1%     326ms ± 1%   -6.34%  (p=0.000 n=10+10)
Mandelbrot200            6.62ms ± 0%    6.64ms ± 0%   +0.37%  (p=0.000 n=7+9)
GoParse                  23.9ms ± 1%    24.7ms ± 1%   +2.98%  (p=0.000 n=9+9)
RegexpMatchEasy0_32       555ns ± 0%     561ns ± 0%   +1.10%  (p=0.000 n=8+10)
RegexpMatchEasy0_1K      3.94µs ± 1%    3.94µs ± 0%     ~     (p=0.906 n=9+8)
RegexpMatchEasy1_32       516ns ± 0%     524ns ± 0%   +1.51%  (p=0.000 n=9+10)
RegexpMatchEasy1_1K      4.39µs ± 1%    4.40µs ± 1%     ~     (p=0.171 n=10+10)
RegexpMatchMedium_32     25.1ns ± 0%    25.5ns ± 0%   +1.51%  (p=0.000 n=9+8)
RegexpMatchMedium_1K      196µs ± 0%     203µs ± 1%   +3.23%  (p=0.000 n=9+10)
RegexpMatchHard_32       11.2µs ± 1%    11.6µs ± 1%   +3.62%  (p=0.000 n=10+10)
RegexpMatchHard_1K        334µs ± 1%     348µs ± 1%   +4.21%  (p=0.000 n=9+10)
Revcomp                   2.39s ± 0%     2.41s ± 0%   +0.78%  (p=0.000 n=8+9)
Template                  385ms ± 1%     336ms ± 0%  -12.61%  (p=0.000 n=10+9)
TimeParse                2.18µs ± 1%    2.18µs ± 1%     ~     (p=0.424 n=10+10)
TimeFormat               2.28µs ± 1%    2.22µs ± 1%   -2.30%  (p=0.000 n=10+10)

name                   old speed      new speed      delta
GobDecode              19.8MB/s ± 1%  20.3MB/s ± 0%   +2.56%  (p=0.000 n=10+8)
GobEncode              29.1MB/s ± 1%  29.2MB/s ± 0%     ~     (p=0.810 n=10+10)
Gzip                   16.7MB/s ± 1%  16.8MB/s ± 0%   +0.37%  (p=0.007 n=10+9)
Gunzip                 92.2MB/s ± 0%  93.2MB/s ± 1%   +1.03%  (p=0.000 n=10+10)
JSONEncode             40.4MB/s ± 0%  40.3MB/s ± 1%   -0.28%  (p=0.025 n=9+9)
JSONDecode             5.58MB/s ± 1%  5.96MB/s ± 1%   +6.80%  (p=0.000 n=10+10)
GoParse                2.42MB/s ± 0%  2.35MB/s ± 1%   -2.83%  (p=0.000 n=8+9)
RegexpMatchEasy0_32    57.7MB/s ± 0%  57.0MB/s ± 0%   -1.09%  (p=0.000 n=8+10)
RegexpMatchEasy0_1K     260MB/s ± 1%   260MB/s ± 0%     ~     (p=0.963 n=9+8)
RegexpMatchEasy1_32    62.1MB/s ± 0%  61.1MB/s ± 0%   -1.53%  (p=0.000 n=10+10)
RegexpMatchEasy1_1K     233MB/s ± 1%   233MB/s ± 1%     ~     (p=0.190 n=10+10)
RegexpMatchMedium_32   39.8MB/s ± 0%  39.1MB/s ± 1%   -1.74%  (p=0.000 n=9+10)
RegexpMatchMedium_1K   5.21MB/s ± 0%  5.05MB/s ± 1%   -3.09%  (p=0.000 n=9+10)
RegexpMatchHard_32     2.86MB/s ± 1%  2.76MB/s ± 1%   -3.43%  (p=0.000 n=10+10)
RegexpMatchHard_1K     3.06MB/s ± 1%  2.94MB/s ± 1%   -4.06%  (p=0.000 n=9+10)
Revcomp                 106MB/s ± 0%   105MB/s ± 0%   -0.77%  (p=0.000 n=8+9)
Template               5.04MB/s ± 1%  5.77MB/s ± 0%  +14.48%  (p=0.000 n=10+9)

Updates #32591

Change-Id: Id567e14a788e359248b2129ef1cf0adc8cc4ab7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/183457
Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Richard Musiol <neelance@gmail.com>
2019-08-28 05:11:20 +00:00
Michael Anthony Knyszek
31c4e09915 runtime: ensure free and unscavenged spans may be backed by huge pages
This change adds a new sysHugePage function to provide the equivalent of
Linux's madvise(MADV_HUGEPAGE) support to the runtime. It then uses
sysHugePage to mark a newly-coalesced free span as backable by huge
pages to make the freeHugePages approximation a bit more accurate.

The problem being solved here is that if a large free span is composed
of many small spans which were coalesced together, then there's a chance
that they have had madvise(MADV_NOHUGEPAGE) called on them at some point,
which makes freeHugePages less accurate.

For #30333.

Change-Id: Idd4b02567619fc8d45647d9abd18da42f96f0522
Reviewed-on: https://go-review.googlesource.com/c/go/+/173338
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
2019-05-06 21:15:01 +00:00
Richard Musiol
c2d9eea1f1 runtime: do not use heap arena hints on wasm
The address space of WebAssembly's linear memory is contiguous, so
requesting specific addresses is not supported. Do not use heap arena
hints so we do not have unused memory ranges.

This fixes go1 benchmarks on wasm which ran out of memory since
https://golang.org/cl/170950.

Change-Id: I70115b18dbe43abe16dd5f57996343d97bf94760
Reviewed-on: https://go-review.googlesource.com/c/go/+/174203
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
2019-04-30 08:25:33 +00:00
Richard Musiol
35ea62468b runtime: add js/wasm architecture
This commit adds the js/wasm architecture to the runtime package.
Currently WebAssembly has no support for threads yet, see
https://github.com/WebAssembly/design/issues/1073. Because of that,
there is no preemption of goroutines and no sysmon goroutine.

Design doc: https://docs.google.com/document/d/131vjr4DH6JFnb-blm_uRdaC0_Nv3OUwjEY5qVCxCup4
About WebAssembly assembly files: https://docs.google.com/document/d/1GRmy3rA4DiYtBlX-I1Jr_iHykbX8EixC3Mq0TCYqbKc

Updates #18892

Change-Id: I7f12d21b5180500d55ae9fd2f7e926a1731db391
Reviewed-on: https://go-review.googlesource.com/103877
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
2018-05-08 00:17:34 +00:00