ng build --prod OOM

Versions

OS: Debian Stretch

     _                      _                 ____ _     ___
    / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
   / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
  / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
 /_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
                |___/


Angular CLI: 6.0.0-rc.7
Node: 8.11.1
OS: linux x64
Angular: 6.0.0-rc.6
... animations, common, compiler, compiler-cli, core, forms
... http, platform-browser, platform-browser-dynamic
... platform-server, platform-webworker
... platform-webworker-dynamic, router, service-worker

Package                            Version
------------------------------------------------------------
@angular-devkit/architect          0.5.10
@angular-devkit/architect-cli      0.5.10
@angular-devkit/build-angular      0.5.10
@angular-devkit/build-ng-packagr   0.5.10
@angular-devkit/build-optimizer    0.5.10
@angular-devkit/build-webpack      0.0.8
@angular-devkit/core               0.5.10
@angular-devkit/schematics         0.5.10
@angular-devkit/schematics-cli     0.5.10
@angular/cdk                       6.0.0-rc.13
@angular/cli                       6.0.0-rc.7
@angular/flex-layout               6.0.0-beta.15
@angular/material                  6.0.0-rc.13
@ngtools/json-schema               1.2.0
@ngtools/webpack                   6.0.0-rc.8
@schematics/angular                0.5.10
@schematics/package-update         0.3.2
@schematics/schematics             0.5.10
@schematics/update                 0.5.10
rxjs                               6.0.0
typescript                         2.7.2
webpack                            4.6.0

Repro steps

• git clone https://github.com/buu700/cyph-ng6-test.git
• cd cyph-ng6-test
• npm install .
• ng build --prod

Observed behavior

                                                                                                                              2                                                                                                                                                                             4                                                                                                                                                                             6                                                                                                                                                                             6                                                                                                                                                                           6                                                                                                                                      92% chunk asset optimization UglifyJSPlugin                                             s
<--- Last few GCs --->

[1712:0x3d4b6e0]   428216 ms: Mark-sweep 1472.2 (1607.6) -> 1472.1 (1607.6) MB, 1500.0 / 0.0 ms  allocation failure GC in old space requested
[1712:0x3d4b6e0]   430995 ms: Mark-sweep 1472.1 (1607.6) -> 1471.9 (1571.6) MB, 2777.9 / 0.0 ms  last resort GC in old space requested
[1712:0x3d4b6e0]   433430 ms: Mark-sweep 1471.9 (1571.6) -> 1471.9 (1568.6) MB, 2433.7 / 0.0 ms  last resort GC in old space requested


<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x2edfc9d257c1 <JSObject>
    1: def_variable [0x4d324d822d1 <undefined>:~5199] [pc=0x1c494a884151](this=0xfcaa76a1f81 <AST_Function map = 0x3c3d27db53c9>,symbol=0x10aafa3b15f1 <AST_SymbolVar map = 0x2493e4398469>,init=0x4d324d82201 <null>)
    2: visit [0x4d324d822d1 <undefined>:~4898] [pc=0x1c494a7874f8](this=0xeb7273e1649 <TreeWalker map = 0x3404dd422ac9>,node=0x10aafa3b15f1 <AST_SymbolVar map = 0x2493e4398469>,descen...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [ng]
 2: 0x11e7fec [ng]
 3: v8::Utils::ReportOOMFailure(char const*, bool) [ng]
 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [ng]
 5: v8::internal::Factory::NewFixedArray(int, v8::internal::PretenureFlag) [ng]
 6: v8::internal::HashTable<v8::internal::StringTable, v8::internal::StringTableShape>::NewInternal(v8::internal::Isolate*, int, v8::internal::PretenureFlag) [ng]
 7: v8::internal::HashTable<v8::internal::StringTable, v8::internal::StringTableShape>::New(v8::internal::Isolate*, int, v8::internal::PretenureFlag, v8::internal::MinimumCapacity) [ng]
 8: v8::internal::HashTable<v8::internal::StringTable, v8::internal::StringTableShape>::EnsureCapacity(v8::internal::Handle<v8::internal::StringTable>, int, v8::internal::PretenureFlag) [ng]
 9: v8::internal::StringTable::LookupString(v8::internal::Isolate*, v8::internal::Handle<v8::internal::String>) [ng]
10: 0x10a21ae [ng]
11: v8::internal::Runtime_KeyedGetProperty(int, v8::internal::Object**, v8::internal::Isolate*) [ng]
12: 0x1c4948d042fd
Aborted

Desired behavior

Successful build.

Mention any other details that might be useful (optional)

Failure occurs in a Docker container with 6.5 GB RAM allocated.

Building without --prod succeeds , and CLI version 1.7.4 works fine.

[crush83]

I’m sorry, but I don’t see it as professionally acceptable for production builds to require 4GB+ of RAM to complete. Our build servers handle many different builds of different products, and the angular production builds by far use 2-10x more resources than any other builds.

Why is this considered acceptable for builds to consume 4GB+ of RAM? Furthermore, it seems like there is no upper bound on what is deemed acceptable. A project could potentially grow to a size that would require 8GB-16GB of RAM…or more…it could potentially scale endlessly until the machine is physically unable to support more RAM. In contrast, I can build a C++ project with 4 million lines of code, and 10 times as many external libraries with 2GB or less…

Are there plans to address this? I understand this probably isn’t the angular-cli directly that is the root issue. However, if it lies with a third party package like webpack, then should it be discussed internally to contribute to webpack to fix this issue - or even try and move away from webpack entirely?

I can’t be the only one who takes extreme issue with the nonchalant stance of “just increase the heap memory available” that seems to be circulating around the issue tracker here.

[aaronte]

^ Seems like I’m using more than the default node memory limit of 1.76 GB.

Changed the ng build command to use 4GB of memory instead and it worked.

node --max_old_space_size=4096 ./node_modules/.bin/ng build --prod