runtime (gc): restructure blocks GC metadata

Originally, the blocks GC simply stored a 2-bit state value for each block with 4 options:
  - umarked head
  - marked head
  - tail (continuation of an object)
  - free

The GC cycled the blocks through these states appropriately.
Then the allocator would search for appropriate ranges of free blocks.

This design resulted in excessive memory fragmentation due to the way that the allocator had to search for free ranges.
To fix this issue, we created a data structure to track the free ranges that is rebuilt after every GC.
This mostly fixed the memory fragmentation issue.

The other issue with this original approach is that it resulted in quadratic performance degredation when scanning free lists.
To solve this, we added a header to each heap object to form a linked stack.
This ensured that each object only needed to be visited once.

As these improvements were made, TinyGo began practically supporting larger and larger heaps.
The current structure where we loop over individual blocks is no longer efficient.
We need to change the metadata to support more efficient traversal.

This commit changes the per-block metadata into a pair of bitmaps: an "ends" bitmap and a "visited" bitmap.
The "ends" bitmap is used by the marking and sweeping logic to find the end (containing the header) of an object.
The "visited" bitmap is to track blocks which have been visited by mark, including both ends and non-ends.
Most operations can be performed by scanning over these bitmaps rather than looping over individual blocks.

The "visited" bitmap also fixes the last remaining case for quadratic performance degredation.
In the event that many pointers referred to the start of a large object, the marking code would scan across the whole object to find the end every time.
The new marking code adds every block between the marked address and the end to the bitmap.
Subsequent marks to the same object will detect the already-visited tail and stop early.

Author: niaow

builder/sizes_test.go

@@ -42,9 +42,9 @@ func TestBinarySize(t *testing.T) {
 	// This is a small number of very diverse targets that we want to test.
 	tests := []sizeTest{
 		// microcontrollers
-		{"hifive1b", "examples/echo", 3705, 299, 0, 2252},
-		{"microbit", "examples/serial", 2736, 356, 8, 2248},
-		{"wioterminal", "examples/pininterrupt", 7960, 1652, 132, 7480},
+		{"hifive1b", "examples/echo", 3799, 297, 0, 2260},
+		{"microbit", "examples/serial", 2802, 354, 8, 2256},
+		{"wioterminal", "examples/pininterrupt", 8048, 1652, 132, 7488},
 
 		// TODO: also check wasm. Right now this is difficult, because
 		// wasm binaries are run through wasm-opt and therefore the

compiler/asserts.go

@@ -93,6 +93,11 @@ func (b *builder) createSliceToArrayPointerCheck(sliceLen llvm.Value, arrayLen i
 // and unsafe.String. This function must panic if the ptr/len parameters are
 // invalid.
 func (b *builder) createUnsafeSliceStringCheck(name string, ptr, len llvm.Value, elementType llvm.Type, lenType *types.Basic) {
+	if b.info.nobounds {
+		// Function disabled bounds checking - skip conversion check.
+		return
+	}
+
 	// From the documentation of unsafe.Slice and unsafe.String:
 	//   > At run time, if len is negative, or if ptr is nil and len is not
 	//   > zero, a run-time panic occurs.
@@ -162,6 +167,11 @@ func (b *builder) createChanBoundsCheck(elementSize uint64, bufSize llvm.Value,
 // It has no effect in well-behaved programs, but makes sure no uncaught nil
 // pointer dereferences exist in valid Go code.
 func (b *builder) createNilCheck(inst ssa.Value, ptr llvm.Value, blockPrefix string) {
+	if b.info.nobounds {
+		// Function disabled bounds checking - skip nil check.
+		return
+	}
+
 	// Check whether we need to emit this check at all.
 	if !ptr.IsAGlobalValue().IsNil() {
 		return