gcinfo() returns truncated memory usage in KB

[zoon]

Summary

The gcinfo() function in luau returns only the integer part of memory usage in KB, stripping the fractional bytes portion that is present in standard lua implementations.

Steps to Reproduce

echo "print(gcinfo())" > test.luau && luau test.luau    # Output: 36

Expected Behavior

Based on standard lua behavior of collectgarbage('count'), gcinfo() should return the memory usage in KB as a floating-point number, including fractional bytes. This value multiplied by 1024 gives the exact number of bytes in use.
For comparison:

• Lua 5.1: 26.814453125
• Lua 5.2: 21.8193359375
• Lua 5.3: 22.8564453125
• Lua 5.4: 20.8408203125

Actual Behavior

Luau returns only the integer part: 36

Test Commands Used

# Standard Lua versions for comparison
lua51 -e "print(collectgarbage('count'))"    # Output: 26.814453125
lua52 -e "print(collectgarbage('count'))"    # Output: 21.8193359375
lua53 -e "print(collectgarbage('count'))"    # Output: 22.8564453125
lua54 -e "print(collectgarbage('count'))"    # Output: 20.8408203125

# Luau behavior
echo "print(gcinfo())" > test.luau && luau test.luau    # Output: 36

Impact

This bug affects:

• Code portability between Lua and Luau
• Memory profiling accuracy
• Applications that rely on precise memory usage measurements

Additional Context

The gcinfo() function is documented as returning "the total heap size in kilobytes", without mentioning that it should be truncated to an integer.

[zeux]

gcinfo returned an integer number in 5.1: https://github.com/lua/lua/blob/98194db4295726069137d13b8d24fca8cbf892b6/lbaselib.c#L187-L216

[zoon]

5.1.5 not :)

sh-5.2$ lua51 -v
Lua 5.1.5  Copyright (C) 1994-2012 Lua.org, PUC-Rio
sh-5.2$ luajit -v
LuaJIT 2.1.1748459687 -- Copyright (C) 2005-2025 Mike Pall. https://luajit.org/
sh-5.2$ lua51 -e "print(collectgarbage('count'))"
26.814453125
sh-5.2$ luajit -e "print(collectgarbage('count'))"
36.1630859375

[zeux]

You are testing collectgarbage("count"), not gcinfo.

[zoon]

My bad, you're absolutely right. gcinfo was deprecated in lua 5.1, but ironically collectgarbage("count") was deprecated in Roblox as well and there is no collectgarbage in LuaB_. Is there a way to get around this?

[zeux]

Note, I'm not necessarily saying changing gcinfo to return fractional kilobytes is wrong; I doubt it will break any users. Just saying gcinfo always was like this.

I'll also note that any application that relies on precision of this information is likely incorrect or misleading anyhow:

1. GC is incremental and sometimes asynchronous and you realistically never know what the "true" allocated size of objects is
2. Obviously different platforms may have different object sizes which would lead to different observed behavior
3. The underlying allocator uses larger pages so the amount of memory used by Luau heap is different from the number returned by gcinfo, and that difference is definitely larger than a kilobyte.

So the motivation here is quite unclear to me, but I don't have a strong opinion one way or the other.

[zoon]

I also don't see any other application besides microbenchmarking.

I have an ambition to write a console microbenchmarking library, beautiful like mitata, with UTF8 colored histograms etc.
I intend for it to work with all existing Luau runtimes: Roblox, lune, luau-repl, lute and possibly vanilla lua.

• Lune (mlua) has all options for collectgarbage(they call lua_gcdirectly from Rust), and "count" works correctly.
• I use a patched luau-repl where I enabled all collectgarbage options, and "count" works correctly.
• In lua-repl and Roblox there's also collectgarbage("count") (deprecated), which returns with kilobyte precision, unlike expected.
• In lbaselib there's only gcinfo, which returns with kilobyte precision, which is correct from lua 5.1 perspective (it was left for partial backward compatibility with lua 5.0), but inconvenient.

If gcinfo returned bytes, then it could always be used for this purpose, if it's available in the current runtime, but now I check for the presence of collectgarbage("count"), and then try to figure out what it returns, in case bytes are divided by 1024 without remainder.
For microbenchmarking, having a byte counter is quite valuable, even without "stop/collect/restart".