| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
