Be smarter of stack<->heap allocations for "larger" systems.

[dgryski]

Since https://github.com/tinygo-org/tinygo/pull/2628 , all allocations larger than 256 bytes are moved to the heap. This might not make sense on systems where the default stack size is larger.

This would also allow a larger work queue size for the garbage collector's mark phase which will reduce the number of full heap rescans on overflow.

[dgryski]

@aykevl I want to fix this; do you have any suggestions for how to determine a "large' vs "small" system. I was thinking for non-small systems to bump the max stack allocation size to 1024 bytes.

[aykevl]

The default stack size is known to the compiler, you could check whether the stack is at least 8kB or so before you allow larger objects to be allocated on the heap.

[dgryski]

Seems easy enough. I'll give it a shot.

[dgryski]

Hmm... guess the compiler is only one half of this, since we need need to get that value to the runtime somehow so we can tune the value of

        markStackSize      = 4 * unsafe.Sizeof((*int)(nil)) // number of to-be-marked blocks to queue before forcing a rescan

[aykevl]

@dgryski huh, why does the runtime need to know this? Is it just so that markStackSize can be larger (as an optimization)?

[dgryski]

Yes, that was one of my goals for this. The size of that stack drastically affects the runtime of the garbage collection cycles.

[aykevl]

We could add a magic function call that returns the configured default stack size, and then allocate the array using make. It should trivially const-propagate and be allocated on the stack instead of the heap (although it might break -opt=0).

That said, I'm thinking of adding a generic way to get system configuration variables that can be read from the runtime or elsewhere. This is mainly intended as a way to get board-specific variables into the runtime and machine packages (things like crystal oscillator configuration), but could also be used for the default stack size.