I'll take a look.

Is it possible that all string steps (the concat values) are not GCed and it kept in memory?

like: having "AA" + "BBB" + "C"

so the following strings are kept in memory:

"AA"
"BBB"
"C"
"AABBB"
"AABBBC"

and having this with a large amount of strings can easily reach the limit

This issue appears to be blocking an upcoming release and is therefore an Urgent Release Blocking Issue as per http://go/chrome-slo#release-blocking-issues. Bumping the priority to P0 to better reflect the urgency.

If this is not a release blocking issue, please adjust the release block field. Adjusting the priority will have no affect, P0 will be re-applied whilever this is marked as a release blocking issue.

Lowering prio and removing RB

I tried to give it a shot but was unsuccessful, I tried to use the ZoneScope in ParserBase<Impl>::ParseBinaryContinuation to free any intermediate concatenation but was unable to make it work as my v8 codebase knowledge is not the best (I'll try to contribute in the future for sure I think it will help me be better Node.js contributor as well)

leszeks@chromium.org Can we revert it?

No, OOMs are generally not considered a reason for revert unless they're memory leaks or reproducible on small examples; this one OOMs on a huge JSON, so it would likely be close to OOMing even without that example. Let me take a quick look now though.

It's a string it doesn't matter that it's building a JSON

And it's quite common for webpack and babel

Also it's not even close to have OOM before that change as it's only 0.5MB

Yeah I agree it's not ideal. I'm thinking we can represent this as a cons string (a "rope") and only flatten at the end -- this would have the advantage that this giant string then also isn't internalized.

That said, this is crashing on heap string allocation, not in the parser...

Project: v8/v8
Branch: main
Author: Leszek Swirski <leszeks@chromium.org>
Link:      https://chromium-review.googlesource.com/5898672

[parser] Fold strings as AstConsString

[parser] Fold strings as AstConsString

To avoid O(N^2) allocations for string constant folding, fold strings as
AstConsString when there is string literal addition, and only flatten
them on final allocation.

This has the consequence that the bytecode constant pool will contain
materialized AstConsStrings, which are currently not internalized. This
shouldn't present a problem since these strings could have equally well
been computed at runtime.

Bug: 368791119
Change-Id: Id1a24e5c076bf6f308e3487f3d4b603ba373ebed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5898672
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#96373}

It's in 131, which should get to stable in mid-November