JavaScript heap out of memory is thrown

[WillooWisp]

We can build only a bare minimum of the application with AOT, when building the whole app with AOT we get out of memory problems.

32599ms additional asset processing 92% chunk asset optimization <--- Last few GCs --->

166208 ms: Mark-sweep 1320.6 (1436.5) -> 1319.8 (1436.5) MB, 1396.1 / 0.0 ms [allocation failure] [GC in old space requested]. 167613 ms: Mark-sweep 1319.8 (1436.5) -> 1319.8 (1436.5) MB, 1404.8 / 0.0 ms [allocation failure] [GC in old space requested]. 169076 ms: Mark-sweep 1319.8 (1436.5) -> 1326.0 (1420.5) MB, 1462.3 / 0.0 ms [last resort gc]. 170586 ms: Mark-sweep 1326.0 (1420.5) -> 1332.4 (1420.5) MB, 1509.0 / 0.0 ms [last resort gc].

[shlomiassaf]

The plugin essentially move things from there to there, the core functionality is in the angular compiler.

Can you please give more details on the setup and project, maybe something to reproduce

[dereklin]

How to do the equivalent of this?:

node --max-old-space-size=8192 node_modules/@angular/compiler-cli/src/main.js -p tsconfig-aot.json

[Koslun]

Have a medium sized app with about 5 lazy-loaded modules and 78 defined components and maybe about 10 forms. It has been stuck on 2.1.1 in JiT mode largely due to depending on the earlier version of Angular Universal.

So have recently been porting it to 4.1.X and AoT using the new Angular Universal project. In this process I have also been seeing the exact same error thrown.

I believe it to be an optimization issue with the angular compiler. Specifically one issue on the angular repo, https://github.com/angular/angular/issues/12184, eventually starts to discuss that the compiler can sometimes use a whole lot of memory, core members chiming in.

The only other one I've seen to actually pin-point a specific possible cause other than "big projects => bad" has to do with the number of form controls in your app 20-30 being bad: https://github.com/angular/angular/issues/11458. It however derails a bit and got locked. Nevertheless it would at least apply to our project, in particular it seems that it is our lazy loaded modules which explode, which is also where all of our forms are. To be specific we use the ReactiveFormModule and not the template-based form module.

The only actionable solution I've found is the one mentioned by @dereklin, allow node to use more RAM. Discussed more in depth in https://github.com/angular/angular/issues/5229 and previously linked issue https://github.com/angular/angular/issues/12184.

Translating the above solution to a gulp project should be to run gulp through node, i.e.:

node --max_old_space_size=4000 node_modules/gulp/bin/gulp.js [<task>]

If you run webpack through the CLI using npm scripts, like almost all starters I've seen, I imagine it'd be something similar for webpack.

So I derailed a lot but think the only real change that can be done in this project would be to add a note of this workaround in the README.md as this needs to be optimized downstream at the angular compiler, as noted by Tobias Bosch in https://github.com/angular/angular/issues/12184#issuecomment-293622751.

[markkasaboski]

Sadly, the above solution won't work for everyone. The memory consumption is obscene to say the least. I've even gone as far as:

node --max_old_space_size=8192 --optimize_for_size --max_executable_size=8192 --stack_size=8192 /usr/local/bin/npm run build

What we need is what Google is using internally and we need it yesterday! https://github.com/angular/angular/issues/12184#issuecomment-293622751