runtime: don't allocate when putting a bool into an interface

[bradfitz]

Shoving a bool into an interface probably doesn't need to allocate. I imagine most binaries already have a static 1 byte and a static 0 byte somewhere whose address we could use in the interface's data pointer.

bradfitz@gdev:~$ cat alloc.go
package main

import "testing"

func main() {
        var x interface{}
        x = true
        println(x)
        x = false
        println(x)
        x = true
        println(x)
        
        println(testing.AllocsPerRun(5000, func() {
                x = true
        }))
}

bradfitz@gdev:~$ go run ~/alloc.go
(0x49b960,0xc42003bf4f)
(0x49b960,0xc42003bf4e)
(0x49b960,0xc42003bf4d)
+1.000000e+000

/cc @josharian @randall77 @mdempsky

[mdempsky]

Relatedly, I've been thinking that converting len-1 []byte to string shouldn't need to allocate either.

[mdempsky]

This can already be done within the runtime in convT2I. I don't believe it needs compiler assistance.

[dr2chase]

How do we feel about smallish integers? Seems like we could profile in convT2I to see how this would pay off. One possible value for smallish is {2,1,0,-1}

[bradfitz]

I feel like last time smallish integers was brought up, the concern was that it would be inconsistent and thus surprising. But with bools at least it would be consistent.

Then again, the better the compiler and runtime get, the more that performance things get surprising, so maybe it's okay nowadays.

I agree some convT2I stats for all this would be interesting.

[mdempsky]

I was thinking we just have a 256-byte slab of "\x00\x01...\xff", and we can index into that for any read-only 1-byte value that needs to be converted to a pointer (e.g., converting a len-1 []byte to string, or storing a bool/byte/int8/uint8 into an interface).

If we instead used [...]int64{..., -3, -2, -1, 0, 1, 2, 3, ...} for a certain range of integers, we could avoid heap allocs for a wider variety of values.

Agreed collecting stats on recognizable patterns would be good.

[josharian]

I was thinking we just have a 256-byte slab of "\x00\x01...\xff"

That was my exact reaction as well.

[randall77]

I had a CL a long time ago which did [...]int64{0..1024}. We ended up not using it because the performance cliff from 1024->1025 would be weird.

The 256-byte one would not have that problem, although it would weirdly encourage people to cram their data into 1 byte chunks.

[josharian]

To spare others the search, that was CL 2500, which in turn also points to #8618. I'd still like to see this get done.

[griesemer]

I'm also still in favor of this. I think the benefits outweigh the oddity in performance behavior.

[bradfitz]

We ended up not using it because the performance cliff from 1024->1025 would be weird.

Clearly we just need to smooth out that cliff with some fastrand(), slowly increasing the chance of allocating from 0 to 1024, where 1025 is 100%! /s

[mrjrieke]

@mdempsky would slow compiler tiny bit.... of course, @bradfitz presents a difficult challenge for prediction with fastrand(). cqtm