process.constrainedMemory() should map UINT64_MAX to 0, per node documentation

[Asaf-Federman]

Version

v22.17.1

Platform

Linux#32-Ubuntu SMP Wed May 28 19:48:56 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

No response

What steps will reproduce the bug?

Execute process.contrainedMemory() on any linux machine without any defined constraints.

How often does it reproduce? Is there a required condition?

When there is a constraining mechanism, but there is no constraint set

What is the expected behavior? Why is that the expected behavior?

According to node documentation, If there is a constraining mechanism, but there is no constraint set, 0 should be returned

What do you see instead?

node
Welcome to Node.js v22.17.1.
Type ".help" for more information.

os.totalmem()
2003443712
process.constrainedMemory()
18446744073709552000

Additional information

This code should be amended

Libuv doc: https://docs.libuv.org/en/v1.x/misc.html#c.uv_get_constrained_memory
Node doc: https://github.com/nodejs/node/blob/main/doc/api/process.md?plain=1#L1086

[Asaf-Federman]

I am happy to address the issue, provided there is an agreed-upon solution.

[lifefloating]

[lifefloating]

@Asaf-Federman

[Asaf-Federman]

@Asaf-Federman

[Asaf-Federman]

Does your operating system include any constraining mechanisms?

[lifefloating]

uname -a
Darwin Darwin Kernel Version 24.5.0: Tue Apr 22 19:54:26 PDT 2025; root:xnu-11417.121.6~2/RELEASE_ARM64_T8112 arm64

[lifefloating]

is that only exists in ubuntu

[theanarkh]

Mapping UINT64_MAX to 0 is semantically inconsistent with libuv. I think we should return v8::BigInt from C++ layer.

[Asaf-Federman]

is that only exists in ubuntu

This type of constraining mechanism is not present on Darwin.
Therefore, the expected return value is 0.

[Asaf-Federman]

Mapping UINT64_MAX to 0 is semantically inconsistent with libuv. I think we should return v8::BigInt from C++ layer.

I think we should follow Node conventions and provide a consistent, high-level abstraction over the lower-level API.

1. If there is no constraining mechanism (i.e. the platform does not support constrained memory reporting): Return: undefined or null (preferred: undefined, since it's idiomatic in Node when something is not available)

2. If constrained memory is supported but not explicitly set (i.e. 0): Return: 0 — means “no explicit constraint configured”

3. If there is a real constraint (a positive number): Return: the actual value in bytes

[theanarkh]

This will be a breaking change because 0 means no constraint or unknow now (#52039).

[Asaf-Federman]

This will be a breaking change because 0 means no constraint or unknow now (#52039).

Yes, it will be a breaking change, but IMHO we need to align with node standards

[bnoordhuis]

-1, needless breaking change. Better: update the documentation.

[Asaf-Federman]

-1, needless breaking change. Better: update the documentation.

So in that case, the only solution is what @theanarkh suggested.