runtime: allow `GOMEMLIMIT` to parse non integer values with a suffix like `1.5GiB` → `1536MiB`

[subnix]

Go version

go version go1.25.5 darwin/arm64

Output of go env in your module/workspace:

AR='ar'
CC='cc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='c++'
GCCGO='gccgo'
GO111MODULE=''
GOARCH='arm64'
GOARM64='v8.0'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/Users/user/Library/Caches/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/Users/user/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/w4/9h406zs53_d82t0jx555j4ww0000gn/T/go-build2324368129=/tmp/go-build -gno-record-gcc-switches -fno-common'
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMOD='/tmp/testgo/go.mod'
GOMODCACHE='/Users/user/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/user/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/opt/homebrew/Cellar/go/1.25.5/libexec'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/user/Library/Application Support/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.25.5/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.25.5'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

GOMEMLIMIT=1.5GiB go run .

What did you see happen?

GOMEMLIMIT=1.5GiB
fatal error: malformed GOMEMLIMIT; see `go doc runtime/debug.SetMemoryLimit`

runtime stack:
runtime.throw({0x10337f090?, 0xa?})
	runtime/panic.go:1094 +0x34 fp=0x16d03eeb0 sp=0x16d03ee80 pc=0x102e367d4
runtime.readGOMEMLIMIT()
	runtime/mgcpacer.go:1365 +0xb4 fp=0x16d03eee0 sp=0x16d03eeb0 pc=0x102de9c14
runtime.gcinit()
	runtime/mgc.go:189 +0x38 fp=0x16d03ef10 sp=0x16d03eee0 pc=0x102de0318
runtime.schedinit()
	runtime/proc.go:898 +0x1c0 fp=0x16d03ef80 sp=0x16d03ef10 pc=0x102e02b70
runtime.rt0_go()
	runtime/asm_arm64.s:121 +0xcc fp=0x16d03efb0 sp=0x16d03ef80 pc=0x102e3c6dc

What did you expect to see?

According to the documentation GOMEMLIMIT is a numeric value with an optional unit suffix:

go/src/runtime/extern.go

Lines 27 to 33 in d00e96d

	program. GOMEMLIMIT is a numeric value in bytes with an optional unit suffix.
	The supported suffixes include B, KiB, MiB, GiB, and TiB. These suffixes
	represent quantities of bytes as defined by the IEC 80000-13 standard. That is,
	they are based on powers of two: KiB means 2^10 bytes, MiB means 2^20 bytes,
	and so on. The default setting is [math.MaxInt64], which effectively disables the
	memory limit. [runtime/debug.SetMemoryLimit] allows changing this limit at run
	time.

And numeric types include:

go/doc/go_spec.html

Lines 841 to 846 in d00e96d

	<h3 id="Numeric_types">Numeric types</h3>
	<p>
	An <i>integer</i>, <i>floating-point</i>, or <i>complex</i> type
	represents the set of integer, floating-point, or complex values, respectively.
	They are collectively called <i>numeric types</i>.

However, GOMEMLIMIT only accepts integers:

go/src/runtime/string.go

Lines 402 to 415 in d00e96d

	// parseByteCount parses a string that represents a count of bytes.
	//
	// s must match the following regular expression:
	//
	// ^[0-9]+(([KMGT]i)?B)?$
	//
	// In other words, an integer byte count with an optional unit
	// suffix. Acceptable suffixes include one of
	// - KiB, MiB, GiB, TiB which represent binary IEC/ISO 80000 units, or
	// - B, which just represents bytes.
	//
	// Returns an int64 because that's what its callers want and receive,
	// but the result is always non-negative.
	func parseByteCount(s string) (int64, bool) {

Therefore, I would expect GOMEMLIMIT to either accept a float value or explicitly specify the types it accepts. For instance, systemd allows specifying memory constraints using a float value with a suffix.

[gabyhelp]

Related Issues

• runtime: miscalculating the memoryLimitGoal in gcPaceScavenger #62449 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[mknyszek]

While this is a nice idea, I don't see much of a use-case.

If you want to be precise about your limit ("90% of some other number") then you probably just want to specify the number of bytes directly. In this case a machine is probably writing out that limit. The purpose behind the "1GiB" etc. is just for quick local checking, where precision doesn't really matter and you mainly just don't want to worry about not having the right number of zeroes.

Simultaneously, I have some concerns with supporting fractional values in terms of representation. I don't want to encourage people to specify a fractional amount that cannot be precisely represented with a simple primitive like an int64 or a float64. I mean, yeah, the precision is probably good enough, but there's something about "floating point rounding error included in my memory limit" that doesn't feel quite right to me.

Supporting fractional values this way at all makes that possible (fixed-point, floating-point, etc. will all have this problem), unless we parse it as a big.Float, which is both difficult (this is parsed early at runtime startup, where only a subset of the runtime is initialized) and seems like overkill. (As an aside, just crashing when the value is not precisely representable also doesn't feel like a great solution, since that's much less predictable than "we don't support fractional values." EDIT: In hindsight I don't think this point makes much sense. float64 has plenty of precision, and is exactly precise up to 53 bits of mantissa, which is more address space than most platforms expose.

FTR, I don't feel that strongly about this. If there's a lot of support for this we can consider it more thoroughly, but it seems like a fairly low priority to me.

As a final note, we could probably make the error message better.

[Jorropo]

I don't think it's that hard to do if we say it MUST resolve to an int amount of bytes (otherwise error) I could throw a pretty simple "float" → int converter in tens of lines of go.
But then it's not that convenient.

I don't see the point tho:

The purpose behind the "1GiB" etc. is just for quick local checking, where precision doesn't really matter and you mainly just don't want to worry about not having the right number of zeroes.

huge 👍

[mknyszek]

I don't think it's that hard to do if we say it MUST resolve to an int amount of bytes (otherwise error) I could throw a pretty simple "float" → int converter in tens of lines of go.

Sure.

Plus, I don't really think my point is against "representation as a floating point value." We have 53 bits of integral precision in a float64 and we rarely have more than 48 bits of address space anyway. I don't think that part is much of an issue.

[Jorropo]

After thinking about it.
I don't see the point of this feature.

But I don't see the point of having it not work either.
It's pretty clear, maybe cost a few lines of code but if someone wants to implement it I don't think it's gonna much time to maintain.

[seankhliao]

who doesn't want to write 0X1.800P+30GiB?
I think this should just accept integers.

[Jorropo]

@seankhliao who is saying 0X1.800P+30GiB should be parsed ?

If you're serious tell me you would rather look at 1536MiB than 1.5GiB.
Do you know how to write 1.75GiB as an int without using a calculator ?

Idk; You could argue that most people would just write 1500MiB or 1700MiB and call it a day but 0X1.800P+30GiB is what we got. ✨

[seankhliao]

I chose that because I remembered an issue somewhere about being too lax in accepting numeric formats.

.5 is easy, but what about other fractions
consider kubernetes/kubernetes#94445
Does the user expect some super precise number, or are they actually just thinking in terms of the next smaller unit?

Personally, I've never used decimals in resource quantities (used a lot in k8s), and the k8s api server normalizes them so it never shows you decimals either.

[adonovan]

You could specify that the required form is [0-9]+ ( [.] [0-9]+ )? ( ([KMG] i?)? B )?, allowing simple decimal fractions of either a power of either 1024 or 1000, which would eliminate the need to support exponents: 1.5e6 would be written 1.5MB. (Obviously this logic would be part of parseByteCount and not internal/strconv.)