Catch unwanted heap allocations at compile-time

[digitalentity]

I have a project where certain code needs to run at a high rate (~1 kHz). I want this code to have zero heap allocations to ensure that GC doesn't affect this high-rate flow.

In golang a programmer generally has very little (if any) control on where the memory is allocated (moreover, sometimes the decisions the compiler makes are non-obvious (see e.g. #5366 where two almost identical pieces of code produced different memory allocation pattern).

What I'd like to have as part of TinyGo is a way to declare a certain function "heap allocation free" which would force the compiler to throw an error if it can't allocate an object on stack.

[eliasnaur]

Please explain why testing.AllocsPerRun is not sufficient for your needs.

Also, should a hypothetical //go:noheap pragma cover only the marked function or its callees as well? If only the function, then that's brittle when you refactor code into allocating sub-functions. On the other hand, if the pragma covers callees what happens when a callee is determined at runtime? Say

type MaybeAllocator interface {
   MaybeAllocate()
}

//go:heap
func MustNotAllocate(o MaybeAllocator)

In short, a pragma cannot statically determine allocations with precision, unlike testing.AllocsPerRun that measures allocations on a particular code path with particular inputs, at runtime.

[digitalentity]

For testing.AllocsPerRun to work reliably we need identical escape analysis behavior between the tinygo build and go test.

Using tinygo test unfortunately doesn't work - the compiler complains about src/internal/reflectlite/type.go:4:2: use of internal package internal/gclayout not allowed and similar.

[aykevl]

Do you mean for that specific function only, or also the functions that function calls? The former is easy, the latter is very difficult (depending on what exactly you want).
For example appending to a slice will call runtime.sliceAppend which may allocate if the slice doesn't have enough capacity.

[digitalentity]

The former. What I'm building is a real-time system. Heap allocations themselves are not a big deal, but the "stop the world" GC can stall the real-time control loop for sufficiently long to cause problems - that's why I want to allow heap allocations only in places where they won't cause issues (e.g. executed once at start-up).

I currently do that with a post-processing script that takes in the output of -print-allocs and a list of "approved locations" (file+line pairs), but that's fragile and annoying to maintain.

[aykevl]

@digitalentity I created #5409, which I think would fit your needs. Can you try it?

[digitalentity]

Works for me! I corrctly get the error like src/alloc_woes/main.go:16: object allocated on the heap in //go:noheap function in functions annotated with //go:noheap. This is exactly what I need.

[aykevl]

Thank you for testing!