Repository navigation
Significant heap usage regression in Node 22.19.0 #59733
Description
Activity
I can confirm the behaviour. Memory consumption more than doubled.
Downgrading to 22.18 reduces back to "normal" memory size.In case it's helpful for others: in our application at least, switching to
date-fnssingle-function imports (e.g.import { isValid } from 'date-fns'->import { isValid } from 'date-fns/isValid') reduced the magnitude of the heap increase significantly, so it does seem pretty package specific. That said, while this workaround works in this specific case, the size of this cache in memory still seems way too big.I looked at the code how the original cache worked and how the new cache works and just by reading the code it seems to roughly contain the same data (now a nested object).
Could you check how much memory it used to use with Node.js 20? It was released in Node.js 21.5 and all 22 and onwards also contain the change with the C++ implementation.@BridgeAR Here are some data points for the reproduction in the original message:
- 20.19.5 - ~5.6 MB heap, ~48 MB RSS
- 21.5.0 - ~5.6 MB heap, ~49 MB RSS
- 22.18.0 - ~6.3 MB heap, ~54 MB RSS
- 22.19.0 - ~28 MB heap, ~76 MB RSS
@BridgeAR I think the big difference between the previous JS-side cache (the one removed in #50322) and the one introduced here is that the original cache was a map from
package.jsonpath to deserializedpackage.jsonmetadata, whereas this is a map from any module file path to deserializedpackage.jsonmetadata. This duplicates cache data when multiple module files share the same parentpackage.jsonfile. This is obviously common in general, but there are also some degenerate cases likedate-fnswhich have a ton of paths and a relatively largepackage.jsonmetadata objectReacted by João Guerra and Ruben BridgewaterJust adding to the discussion, something has definitely changed in regards to memory between Node.JS 22.18 and 22.19. We have started seing 139 exit codes on the startup process of many applications and the increased heap usage mentioned. Downgrading to NodeJS 20 or 22.18 "fixes" the issue for us.
Reacted by João Guerra, uB4nshee, Alan Gomes, Jérémy Fauvel, Alex VrV, Konstantinos Tsanakas and Ronaldo TafarelSame in our team, we have seen an increase of 100MB across most of our apps.
A previous commentor mentioned date-fns, we definitely use that library and it might be responsible for the larger than average increase. Will report back if I manage to do some testing with and without.@michaelsmithxyz that sounds right. Since you already looked into the issue, would you mind opening a PR to fix that?
Reacted by Michael Smith
Version
v22.19.0
Platform
Subsystem
No response
What steps will reproduce the bug?
Node 22.19.0 uses significantly more heap memory than 22.18.0. I think it's because of this change, which introduces a cache for
package.jsonmetadata. Some packages are structured in such a way that this cache ends up quite large. The reproduction provided here usesdate-fns, which exhibits this clearly.To reproduce, compare heap snapshots for a script like this:
{ "dependencies": { "date-fns": "^4.1.0" } }In my testing, the total heap size for this script on 22.18 is ~7.2 MB, whereas on 22.19 it's ~28.9 MB. This was originally detected in a medium size application where an upgrade to 22.19 ballooned heap usage by more than 50 MB. Inspecting a heap snapshot shows that much of this increase is accounted for by objects retained by
nearestParentPackageJSONCacheHow often does it reproduce? Is there a required condition?
It reproduces consistently on 22.19.0
What is the expected behavior? Why is that the expected behavior?
I would not expect such a significant increase in heap usage
What do you see instead?
A significant increase in heap usage
Additional information
A zip containing heap snapshots for the reproduction script is attached
HeapSnapshots.zip