| Age | Commit message (Collapse) | Author |
|---|
|
In preparation for being able to run a go program that has code
in several objects, this changes from having several linker
symbols used by the runtime into having one linker symbol that
points at a structure containing the needed data. Multiple
object support will construct a linked list of such structures.
A follow up will initialize the slices in the themoduledata
structure directly from the linker but I was aiming for a minimal
diff for now.
Change-Id: I613cce35309801cf265a1d5ae5aaca8d689c5cbf
Reviewed-on: https://go-review.googlesource.com/7441
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
This is an experiment to see if removing the boundary bit logic will
lead to fewer cache misses and improved performance. Instead of using
boundary bits we use the span information to get element size and use
some bit whacking to get the boundary without having to touch the
random heap bits which cause cache misses.
Furthermore once the boundary bit is removed we can either use that
bit for a simpler checkmark routine or we can reduce the number of
bits in the GC bitmap to 2 bits per pointer sized work. For example
the 2 bits at the boundary can be used for marking and pointer/scalar
differentiation. Since we don't need the mark bit except at the
boundary nibble of the object other nibbles can use this bit
as a noscan bit to indicate that there are no more pointers in
the object.
Currently the changed included in this CL slows down the garbage
benchmark. With the boundary bits garbage gives 5.78 and without
(this CL) it gives 5.88 which is a 2% slowdown.
Change-Id: Id68f831ad668176f7dc9f7b57b339e4ebb6dc4c2
Reviewed-on: https://go-review.googlesource.com/6665
Reviewed-by: Austin Clements <austin@google.com>
|
|
These benchmarks show the effect of the combination of this change
and Rick's pending CL 6665. Code with interior pointers is helped
much more than code without, but even code without doesn't suffer
too badly.
benchmark old ns/op new ns/op delta
BenchmarkBinaryTree17 6989407768 6851728175 -1.97%
BenchmarkFannkuch11 4416250775 4405762558 -0.24%
BenchmarkFmtFprintfEmpty 134 130 -2.99%
BenchmarkFmtFprintfString 491 402 -18.13%
BenchmarkFmtFprintfInt 430 420 -2.33%
BenchmarkFmtFprintfIntInt 748 663 -11.36%
BenchmarkFmtFprintfPrefixedInt 602 534 -11.30%
BenchmarkFmtFprintfFloat 728 699 -3.98%
BenchmarkFmtManyArgs 2528 2507 -0.83%
BenchmarkGobDecode 17448191 17749756 +1.73%
BenchmarkGobEncode 14579824 14370183 -1.44%
BenchmarkGzip 656489990 652669348 -0.58%
BenchmarkGunzip 141254147 141099278 -0.11%
BenchmarkHTTPClientServer 94111 93738 -0.40%
BenchmarkJSONEncode 36305013 36696440 +1.08%
BenchmarkJSONDecode 124652000 128176454 +2.83%
BenchmarkMandelbrot200 6009333 5997093 -0.20%
BenchmarkGoParse 7651583 7623494 -0.37%
BenchmarkRegexpMatchEasy0_32 213 213 +0.00%
BenchmarkRegexpMatchEasy0_1K 511 494 -3.33%
BenchmarkRegexpMatchEasy1_32 186 187 +0.54%
BenchmarkRegexpMatchEasy1_1K 1834 1827 -0.38%
BenchmarkRegexpMatchMedium_32 427 412 -3.51%
BenchmarkRegexpMatchMedium_1K 154841 153086 -1.13%
BenchmarkRegexpMatchHard_32 7473 7478 +0.07%
BenchmarkRegexpMatchHard_1K 233587 232272 -0.56%
BenchmarkRevcomp 918797689 944528032 +2.80%
BenchmarkTemplate 167665081 167773121 +0.06%
BenchmarkTimeParse 631 636 +0.79%
BenchmarkTimeFormat 672 666 -0.89%
Change-Id: Ia923de3cdb3993b640fe0a02cbe2c7babc16f32c
Reviewed-on: https://go-review.googlesource.com/6782
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
|
|
Previously, the typeDead check in greyobject was under a separate
!useCheckmark conditional. Put it with the rest of the !useCheckmark
code. Also move a comment about atomic update of the marked bit to
where we actually do that update now.
Change-Id: Ief5f16401a25739ad57d959607b8d81ffe0bc211
Reviewed-on: https://go-review.googlesource.com/6271
Reviewed-by: Rick Hudson <rlh@golang.org>
|
|
We need to distinguish pointers to free spans, which indicate bugs in
our pointer analysis, from pointers to never-in-the-heap spans, which
can legitimately arise from sysAlloc/mmap/etc. This normally isn't a
problem because the heap is contiguous, but in some situations (32
bit, particularly) the heap must grow around an already allocated
region.
The bad pointer test is disabled so this fix doesn't actually do
anything, but it removes one barrier from reenabling it.
Fixes #9872.
Change-Id: I0a92db4d43b642c58d2b40af69c906a8d9777f88
Reviewed-on: https://go-review.googlesource.com/5780
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
|
|
The slow path of heapBitsForObjects somewhat subtly assumes that the
pointer will not point to the first word of the object and will round
the pointer wrong if this assumption is violated. This assumption is
safe because the fast path should always take care of this case, but
there's no benefit to making this assumption, it makes the code more
difficult to experiment with than necessary, and it's trivial to
eliminate.
Change-Id: Iedd336f7d529a27d3abeb83e77dfb32a285ea73a
Reviewed-on: https://go-review.googlesource.com/5636
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
Move code from malloc1.go, malloc2.go, mem.go, mgc0.go into
appropriate locations.
Factor mgc.go into mgc.go, mgcmark.go, mgcsweep.go, mstats.go.
A lot of this code was in certain files because the right place was in
a C file but it was written in Go, or vice versa. This is one step toward
making things actually well-organized again.
Change-Id: I6741deb88a7cfb1c17ffe0bcca3989e10207968f
Reviewed-on: https://go-review.googlesource.com/5300
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>
|
|
The code in mfinal.go is moved from malloc*.go and mgc*.go
and substantially unchanged.
The code in mbitmap.go is also moved from those files, but
cleaned up so that it can be called from those files (in most cases
the code being moved was not already a standalone function).
I also renamed the constants and wrote comments describing
the format. The result is a significant cleanup and isolation of
the bitmap code, but, roughly speaking, it should be treated
and reviewed as new code.
The other files changed only as much as necessary to support
this code movement.
This CL does NOT change the semantics of the heap or type
bitmaps at all, although there are now some obvious opportunities
to do so in followup CLs.
Change-Id: I41b8d5de87ad1d3cd322709931ab25e659dbb21d
Reviewed-on: https://go-review.googlesource.com/2991
Reviewed-by: Keith Randall <khr@golang.org>
|
