[Lambda][Node.js] Pointer compression / memory-optimized runtime option for large bundles and source maps

Hi Lambda team,

We hit a practical memory wall with Node.js Lambda and wanted to ask if pointer compression (or an equivalent runtime-level memory optimization) is on the roadmap for managed Node runtimes.

Our use case is a backend Lambda with a single-file minified bundle. Normal artifact size is ~7.6 MB. If we enable source maps for debugging (`NODE_OPTIONS=--enable-source-maps`), artifact size jumps to ~31.7 MB (`index.mjs` + `index.mjs.map`).

What we observed in real traffic tests:
- Runtime: Node.js 24.x
- Arch: arm64
- Memory: 256 MB
- Without source maps: cold starts are acceptable for our use case
- With source maps enabled: cold start increases, and we started seeing `Runtime.OutOfMemory` at 256 MB in the editor/debug environment

We can work around this by disabling source maps or increasing memory, but this is a tough tradeoff:
- disabling source maps hurts debuggability
- increasing memory increases cost for workloads that are otherwise lightweight

Request:
Could Lambda provide either:
1. managed Node runtimes with V8 pointer compression enabled, or
2. another runtime-level memory optimization path for Node workloads with large bundles/maps?

Even an experimental/runtime flag path would already help for debugging-heavy environments.

Thanks for considering this.

L’issue ne mentionne aucun fichier du dépôt, test ou point d’entrée de l’implémentation. Commencez par examiner les observations concernant Node.js 24.x, arm64 et 256 MB, ainsi que la demande de pointer compression ou d’une option équivalente pour le runtime géré ; sa résolution nécessiterait une solution au niveau du runtime AWS Lambda ou une voie expérimentale documentée.

Rédigé par le modèle d'indexation à partir du texte de l'issue.