Feature Request: Percentage-Based --max-old-space-size for Dynamic Memory Allocation

[Asaf Federman]

Summary

Currently, --max-old-space-size requires a fixed memory value in MB. However, in containerized environments (e.g., Docker, Kubernetes), available memory can vary dynamically. Introducing a percentage-based option would allow Node.js to adjust its memory usage relative to total system memory, reducing the risk of OOMKills while optimizing performance.

Why is this needed?

• Improves compatibility with containerized environments where memory limits are dynamic.
• Prevents over-allocation & OOMKills when memory limits change.
• Simplifies memory management, eliminating the need for external scripts to compute heap size dynamically.

Proposed Solution

Introduce a new syntax for --max-old-space-size, allowing it to accept a percentage of total system memory, e.g.:

node --max-old-space-size=80% app.js

Example Behavior:

• On a system with 4GB RAM, --max-old-space-size=80% would set it to 3.2GB.
• On a system with 1GB RAM, it would set it to 800MB.

Alternatives Considered

• Manually setting a fixed value, which requires prior knowledge of system memory.
• Using external scripts (os.totalmem()) to calculate heap size dynamically.

Request for Guidance

I’m new to contributing to V8 and would appreciate any guidance on the best way to approach this change. Specifically:

• Are there existing discussions or work related to this idea?
• Which parts of the V8 codebase should I explore for implementing this?
• Any recommended best practices or similar features I should reference?

Looking forward to your feedback and help! 🚀

[Omer Katz (chromium.org)]

Hi Asaf,

I don't think you need V8 to support this.

Node could introduce a flag for it, compute the actual max old space size in MB based on your percentage and the system memory, and pass that to V8 via the existing flag.

That even sounds simpler to me.

Omer

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/v8-dev/e44b0fcd-35a2-4d81-84df-a2fecdabd33en%40googlegroups.com.

[Asaf Federman]

Hi Omer,
Thanks for taking the time to respond.

I've already opened an issue in github perior to the discussion here.

https://github.com/nodejs/node/issues/57447#issuecomment-2738164130

LMK what you think

ב-יום חמישי, 20 במרץ 2025 בשעה 10:42:36 UTC+2, omer...@chromium.org כתב/ה:

[Omer Katz (chromium.org)]

My personal opinion is that your proposal doesn't make things worse (as you've also mentioned in the node discussion) but, since percentages can be converted to MB before reaching V8, I don't see the motivation for adding this to V8.

I personally disagree with bnoordhuis that V8 is the better place for it and I think it makes more sense to have it as a wrapper downstream (i.e. in this case in node).

To view this discussion visit https://groups.google.com/d/msgid/v8-dev/a8fb7122-b63d-4fdf-9e3f-f46ac9e69bcbn%40googlegroups.com.

[Michael Lippautz]

I think relative limits are something better left to embedders of V8. Embedders can define policies (e.g. X% of whatever memory limit they want) and just set the appropriate number. 

To view this discussion visit https://groups.google.com/d/msgid/v8-dev/CAJFGqfN%3DFRm7b1bS7F%2B6tXUjjZNzAx8Nkk52XGCA80L1zj%2BNhw%40mail.gmail.com.

[Ben Noordhuis]

On Thu, Mar 20, 2025 at 12:36 PM Omer Katz (chromium.org)
<omer...@chromium.org> wrote:
>

> My personal opinion is that your proposal doesn't make things worse (as you've also mentioned in the node discussion) but, since percentages can be converted to MB before reaching V8, I don't see the motivation for adding this to V8.
> I personally disagree with bnoordhuis that V8 is the better place for it and I think it makes more sense to have it as a wrapper downstream (i.e. in this case in node).

The downside of doing things downstream is that only node benefits,
not other embedders like Chrome or Deno...

...but the counterargument to that is that node will likely do a
better job than V8, unless V8 is willing to go all in on cgroups
parsing, like OpenJDK. Node gets that for free from libuv.

[Omer Katz (chromium.org)]

On Thu, Mar 20, 2025 at 10:03 PM Ben Noordhuis <in...@bnoordhuis.nl> wrote:

On Thu, Mar 20, 2025 at 12:36 PM Omer Katz (chromium.org)
<omer...@chromium.org> wrote:
>
> My personal opinion is that your proposal doesn't make things worse (as you've also mentioned in the node discussion) but, since percentages can be converted to MB before reaching V8, I don't see the motivation for adding this to V8.
> I personally disagree with bnoordhuis that V8 is the better place for it and I think it makes more sense to have it as a wrapper downstream (i.e. in this case in node).

The downside of doing things downstream is that only node benefits,
not other embedders like Chrome or Deno....

There is no demand for this feature on the Chrome side, so it's fine that Chrome won't benefit from it.

 

...but the counterargument to that is that node will likely do a
better job than V8, unless V8 is willing to go all in on cgroups
parsing, like OpenJDK. Node gets that for free from libuv.

"Going all in on cgroups" is not enough since cgroups is Linux specific and V8 supports other platforms as well.

I don't anticipate V8 making an investment in that area any time soon.

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/v8-dev/CAHQurc-ejataSugnX2O%3D3jjtrtjhEg-7ta34ARApfMh4SEf76w%40mail.gmail.com.