tree 3124f760370859fc9b10564617727bdd17d52dad
parent ef56097f4ea848d48fbf61eba1c757fe7fce99d3
author Ian Lance Taylor <iant@golang.org> 1479359573 -0800
committer Ian Lance Taylor <iant@golang.org> 1494271595 +0000

runtime: copy garbage collector from Go 1.8 runtime

This giant patch replaces the old Go 1.4 memory allocator and garbage
collector with the new Go 1.8 code.  The memory allocator is fairly
similar, though now written in Go rather than C.  The garbage
collector is completely different.  It now uses ptrmask and gcprog
information, which requires changes in the compiler and the reflect
package as well as the runtime.  And, of course, the garbage collector
now runs concurrently with program execution.

In the gc toolchain the garbage collector is strict and precise at all
levels.  In the gofrontend we do not have stack maps, so stacks, and
register values, are collected conservatively.  That means that an
old, no longer used, pointer on a stack or in a register can cause a
memory object to live longer than it should.  That in turns means that
we must disable some checks for invalid pointers in the garbage
collection code.  Not only can we get an invalid pointer on the stack;
the concurrent nature of the collector means that we can in effect
resurrect a block that was already unmarked but that the collector had
not yet gotten around to freeing, and that block can in turn point to
other blocks that the collector had managed to already free.  So we
must disable pointer checks in general.  In effect we are relying on
the fact that the strict pointer checks in the gc toolchain ensure
that the garbage collector is correct, and we just assume that it is
correct for the gofrontend since we are using the same code.

Change-Id: Ic7581f1a8ae9113d857f26ccdf536366114255bc
Reviewed-on: https://go-review.googlesource.com/41307
Reviewed-by: Than McIntosh <thanm@google.com>