add gc layout for some basic types

[dgryski]

No description provided.

[dgryski]

For #4479

[ydnar]

Could this check < size of pointer?

[dgryski]

Yeah, I was just being ultra-conservative for this initial POC, and also my test case was focussed on strings. This could absolutely be smarter.

[dgryski]

Here's the result of https://github.com/dgryski/trifles/tree/master/tinyjsonbench with the layout patches:

   3.1  +
        |                   |
        |         +---------*---------+
        |         +-------------------+
        |                   |
   3.0  +
        |
        |
        |
   2.9  +                                        *
        |
        |
        |                                        |
   2.8  +                              +-------------------+
        |                              +---------*---------+
        |                              +-------------------+
        |                                        |
   2.7  +--------------------------------------------------------------
                        old.times            new.times

File       N   Mean  Stddev
old.times  20  3.06  0.02    (control)
new.times  20  2.79  0.04    (2.79 < 3.06 ± 0.02, p = .000)

and on wasi

        |
  10.0  +
        |
        |
   9.8  +                   |
        |                   |
        |                   |
   9.6  +                   |
        |         +-------------------+
        |         |         *         |
        |         +-------------------+          |
   9.4  +                   |                    |
        |                   |          +---------*---------+
        |                              +-------------------+
   9.2  +                                        |
        |
        |
   9.0  +--------------------------------------------------------------
                        old.times            new.times

File       N   Mean  Stddev
old.times  20  9.49  0.11    (control)
new.times  20  9.31  0.07    (9.31 < 9.49 ± 0.06, p = .000)

[dgryski]

Ideally I think the layout should be computed by the compiler and stored with the rest of the type info data, but I'm leaving that for a later PR. I just did the easy ones for now.

[aykevl]

Good idea! It's one of those "I should do that some day" but never actually did.

[aykevl]

This is probably best solved by a small compiler change that will pass the layout to runtime.sliceAppend (like it does today with runtime.alloc).

[dgryski]

PTAL. I think I've addressed everything except the compiler change to pass more type info to the runtime slice functions.

[ydnar]

Is a GC layout in this PR the same thing that big Go refers to as a GC shape?

[dgryski]

@ydnar Yes, basically. (For those playing along at home: https://github.com/golang/proposal/blob/master/design/generics-implementation-dictionaries-go1.18.md )

For our implementation, see https://github.com/tinygo-org/tinygo/blob/dev/src/runtime/gc_precise.go .

[aykevl]

Is a GC layout in this PR the same thing that big Go refers to as a GC shape?

More or less (source):

The GC shape of a type means how that type appears to the allocator / garbage collector. It is determined by its size, its required alignment, and which parts of the type contain a pointer.

The TinyGo GC layout value doesn't contain alignment and it barely contains size (it doesn't repeat pointer locations, so for a slice or array it would only use the element layout and expect the GC to repeat that). But most importantly, it contains information on which parts (may) contain a pointer - or rather, which parts most definitely don't contain a pointer.

Also, am I glad now that I wrote some rather extensive documentation for this feature!

[aykevl]

LGTM. Assuming it passes the test corpus, I think this is fine to merge?

[dgryski]

Yes, it passes the test corpus. If you're happy with the code in gclayout.go that constructs the layout bits, then yes we can merge this.

[aykevl]

Interestingly there are some binary size and RAM usage changes:

flash                          ram
before   after   diff          before   after   diff
[...]
244264  245468   1204   0.49%    9516   10488    972  10.21% tinygo build -size short -o ./build/test.hex -target=nano-rp2040 -stack-size 8kb ./examples/net/websocket/dial/
285816  287104   1288   0.45%   17240   18212    972   5.64% tinygo build -size short -o ./build/test.hex -target=wioterminal -stack-size 8kb ./examples/net/mqttclient/paho/
337000  338372   1372   0.41%   15748   15396   -352  -2.24% tinygo build -size short -o ./build/test.hex -target=matrixportal-m4 -stack-size 8kb ./examples/net/webstatic/
284680  286076   1396   0.49%   18172   17812   -360  -1.98% tinygo build -size short -o ./build/test.hex -target=wioterminal -stack-size 8kb ./examples/net/webserver/
295148  296612   1464   0.50%   12760   13788   1028   8.06% tinygo build -size short -o ./build/test.hex -target=pyportal -stack-size 8kb ./examples/net/http-get/

These don't use the precise GC yet, and the changes are too large to reasonably be caused by the added code in this PR, so I think these are actually due to interp changes. Which I think is a good thing?