An additional keywords for controlling memory allocation

[digitalentity]

It is common for bare-metal systems to allocate variables statically. The golang is trying to be smart with how it allocates memory (stack/heap). You can also declare a variable statically, but it will have to be declared at a package scope.

Suggestion here is to introduce new keywords (extending the Go language spec):

• static: force allocation on the BSS (statically)
• stack: force allocation on the stack (even if it the compiler can't determine whether it is safe)

E.g.:

static v1 := f() // v1 will always be allocated on the BSS
static var v2 [10]int64 // v2 will be allocated statically with the slice size of 10
static var v3 []int64 //  possibly a compile error, slize size is zero and can't grow because it is forced to be static

stack v2 := f() // v4 will always be allocated on the stack
stack var v5 int64 // v5 will be allocated on the stack

[eliasnaur]

Prior art

What are you trying to achieve? New non-standard keywords and loss of soundness are a very high cost for questionable value. TinyGo's escape analysis is not as strong as Big Go (example 1 example 2), but effort is better spending improving the escape analyser than adding new keywords.

[digitalentity]

Thanks for the prior art.

I'm trying to disable heap allocation where I don't want it to happen, e.g. high frequency (1-2 kHz) event handling.

YOLO'ing it may mean that the compiler will allocate things on the heap every iteration, exhaust the memory and risk triggering garbage collection.

Using -gc=none will also force me to not use goroutines (because they need to be allocated on heap). A viable alternative might be can selectively disable heap allocator for certain packages.

[eliasnaur]

Can you show a minimal reproducer that allocates memory that might have stayed on the stack? It's likely you can refactor your code to please the compiler and not allocate.

[digitalentity]

This is a snippet of the code where the first line is causing allocation on the heap:

errorMag := vec3.Cross(&e.mEf, &vMagRefEf)
errorMag = e.invOrientation.RotatedVec3(&errorMag)
errorMag.Scale(e.config.KpMag)
e.totalCorrection = vec3.Add(&e.totalCorrection, &errorMag)

Libraries used are github.com/ungerik/go3d/vec3, github.com/ungerik/go3d/quaternion.

Interestingly, the same code in a different place (using different variables, but exactly the same functions) is not causing the heap allocation:

errorHdg := vec3.Cross(&fwdEf, &refEf)
errorHdg = e.invOrientation.RotatedVec3(&errorHdg)
errorHdg.Scale(e.config.KpHdg)
e.totalCorrection = vec3.Add(&e.totalCorrection, &errorHdg)

The vec3.Cross always creates a new object and is implemented as follows:

func Cross(a, b *T) T {
	return T{
		a[1]*b[2] - a[2]*b[1],
		a[2]*b[0] - a[0]*b[2],
		a[0]*b[1] - a[1]*b[0],
	}
}

There is no reason for two snippets of code to allocate memory differently, but they do...

[digitalentity]

I can obviously refactor the code to use a statically allocated intermediate variable, but this doesn't really help - I'll have to hunt for unnecessary allocations all the time, instead of having the compiler to flag them for me.

[eliasnaur]

Do you know about the TinyGo -print-allocs flag? It prints allocations at locations that match a regular expression.

Cross looks it shouldn't cause any heap allocations. Does Big Go allocate for the code snippets you provided? If not, that's what you want to fix in TinyGo, not add new keywords.

[digitalentity]

Do you know about the TinyGo -print-allocs flag? It prints allocations at locations that match a regular expression.

Yes, that's how I figured out that heap alloc is happening here. Unfortunately it no longer prints the reason for allocating on heap...

As for the Big Go - I don't know exactly, but from instrumenting the unit-tests it seems that this code path doesn't trigger heap allocs.

[digitalentity]

Did a bit more digging and the reason for heap allocation seems to be this:

func (vec *T) Scale(f float32) *T {
	vec[0] *= f
	vec[1] *= f
	vec[2] *= f
	return vec
}

The function returns the pointer to the object which the compiler probably considers dangerous enough. The caller discards the return value, but the compiler seems to ignore this in this particular case.

If I unroll the function like this:

errorMag := vec3.Cross(&e.mEf, &vMagRefEf)
errorMag = e.invOrientation.RotatedVec3(&errorMag)
errorMag[0] *= e.config.KpMag
errorMag[1] *= e.config.KpMag
errorMag[2] *= e.config.KpMag
e.totalCorrection = vec3.Add(&e.totalCorrection, &errorMag)

the heap allocation doesn't happen anymore.

Still not clear why the compiler correctly identified that the object doesn't escape in the other case - #5366 (comment)

[digitalentity]

I can confirm that returning a pointer to the object is the problematic pattern.

Calling Normalize() causes the object to be re-allocated on the heap (note that it calls Scale() under the hood:

type T [3]float32

func (vec *T) Normalize() *T {
	sl := vec.LengthSqr()
	if sl < Epsilon {
		// Vector is effectively zero
		return vec
	}
	if math.Abs(sl-1) < Epsilon {
		// Vector is already normalized
		return vec
	}
	return vec.Scale(1 / math.Sqrt(sl))
}

func (vec *T) Scale(f float32) *T {
	vec[0] *= f
	vec[1] *= f
	vec[2] *= f
	return vec
}

[dgryski]

I'd love to be able to rely on LLVM's capture tracking to improve our heap->stack optimization pass. Also, from a Go standpoint a pragma is much nicer than an additional keyword. Something else that would be nice (and would go along with -print-allocs=. is a function pragma that would fail if a particular function had any heap allocations. (I know I've had issues where I accidentally had a heap allocation while working on the garbage collector -- that lead to some interesting bugs...)

[digitalentity]

There is a pragma //go:noescape for functions that are not written in Go. Maybe we can introduce the //go:noheap pragma to prevent escapes to heap in an annotated function (and a compilation error if a heap escape happens).

[eliasnaur]

A pragma covers a single function, and is non-standard. testing.AllocsPerRun covers more than a function and is in the standard library.

[digitalentity]

testing.AllocsPerRun would work if the TinyGo produced the same code as Bug Go. I've tested this already (#5366 (comment)) and the test instrumentation showed zero heap allocations, but the tinygo still did allocate things on heap.

[eliasnaur]

testing.AllocsPerRun would work if the TinyGo produced the same code as Bug Go. I've tested this already (#5366 (comment)) and the test instrumentation showed zero heap allocations, but the tinygo still did allocate things on heap.

You're now talking about TinyGo failing to elide heap allocations, which won't change by adding //go:noheap.

I suggest closing this issue and opening a discussion instead.

[digitalentity]

My goal is to eliminate unwanted heap allocations - either by explicitly telling the compiler how to allocate things or make heap allocations in unwanted places compile-time errors so refactoring could be applied to avoid them.

I'll move this to a discussion.