Print attempted allocation size when panicing OOM

[anuraaga]

No description provided.

[dgryski]

For consistency, we should probably define something like this in runtime/panic.go:

func oomPanic(size uintptr) {
                     // pretend to be a runtime panic, but without allocating
                     printstring("panic: runtime error: out of memory allocating ")
					printuint64(uint64(size))
					println(" bytes")
					abort()

}

but otherwise I like this idea.

[anuraaga]

Thanks, did that and added to gc_leaking too

[dgryski]

LGTM

[aykevl]

I would like to check the code size impact of this change before accepting it.

[deadprogram]

@aykevl could you please perform your check so we can unblock this PR?

[dgryski]

Changing my mind on this. It seems unlikely that we particularly care about the last straw to break the camels back, rather than the story about all the other allocations that are filling up the heap.

[anuraaga]

The main reason for this is to easily know it is indeed out of memory and not a too huge allocation, e.g. some logic bug causing a 6GB allocation

[aykevl]

I did a quick check and this change adds around 100 bytes of binary size in most cases, and sometimes much more.

Changing my mind on this. It seems unlikely that we particularly care about the last straw to break the camels back, rather than the story about all the other allocations that are filling up the heap.

Yes indeed. The last allocation is not the full story. It does catch very large allocations but that's a very specific error. While I agree this change will be useful in some specific cases, I do not think we should add this error message to every binary compiled with TinyGo (which might already be very tight on space).

[anuraaga]

Ok no problem. #3302 is more important btw :)