Out of memory error when using ImmutableJS

[sccolbert]

Simply importing the type definitions of ImmutableJS is enough to crash the compiler with an out of memory exception.

TypeScript Version: 2.4.1

index.ts

import 'immutable';

package.json

{
  "private": true,
  "name": "scratch",
  "version": "0.0.1",
  "dependencies": {
    "immutable": "4.0.0-rc.2"
  },
  "devDependencies": {
    "typescript": "^2.4.1"
  },
  "scripts": {
    "build": "tsc"
  }
}

tsconfig.json

{
  "compilerOptions": {
    "declaration": true,
    "noImplicitAny": true,
    "noEmitOnError": true,
    "noUnusedLocals": true,
    "module": "commonjs",
    "moduleResolution": "node",
    "target": "ES5",
    "lib": ["ES5"],
    "types": []
  }
}

Expected behavior:

npm run build should execute cleanly.

Actual behavior:

Out of memory error:

E:\Development\sccolbert\scratch>npm run build

> scratch@0.0.1 build E:\Development\sccolbert\scratch
> tsc


<--- Last few GCs --->

   24342 ms: Mark-sweep 1373.9 (1434.6) -> 1373.9 (1434.6) MB, 1130.9 / 0.0 ms [allocation failure] [GC in old space requested].
   25469 ms: Mark-sweep 1373.9 (1434.6) -> 1373.7 (1434.6) MB, 1126.1 / 0.0 ms [allocation failure] [GC in old space requested].
   26600 ms: Mark-sweep 1373.7 (1434.6) -> 1374.9 (1418.6) MB, 1131.4 / 0.0 ms [last resort gc].
   27744 ms: Mark-sweep 1374.9 (1418.6) -> 1376.0 (1418.6) MB, 1143.2 / 0.0 ms [last resort gc].


<--- JS stacktrace --->

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

Security context: 00000294DA0CFB61 <JS Object>
    1: getTypeOfSymbol [E:\Development\sccolbert\scratch\node_modules\typescript\lib\tsc.js:~25490] [pc=000003AB5C58E243] (this=000000CA3E8662F9 <JS Global Object>,symbol=000001704DD798E1 <a Symbol with map 0000003478D59B29>)
    2: forEachMatchingParameterType [E:\Development\sccolbert\scratch\node_modules\typescript\lib\tsc.js:~30013] [pc=000003AB5C4F801C] (this=000000CA3E8662F9 <JS Global ...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

[radix]

I'm not getting an out-of-memory error, but it is going very slow and I do get strange errors about using Map.merge with a Map argument, saying that it can't unify a Map<K,V> with a Collection<K,V>. 2.4.0 does not have these problems.

[sccolbert]

As an fyi, setting the --noStrictGenerics flag works around the problem for me, but I'm not exactly sure what that flag is doing.

[mceachen]

@sccolbert I've found a workaround for my OOM: #17097 (comment)

[sandersn]

immutable-js/immutable-js#1285 fixes or works around the out-of-memory crash as well as fixing new type errors by TS 2.4. However, my investigation didn't turn up any regressions in the compiler — just the same old explosion in assignability checking for mutually referential types.

Here is a small standalone repro that I made:

interface Funkadelic<T> { t: T }
interface Collection<K, V> {
    //map<M>(mapper: (value: V, key: K, iter: this) => M): Collection<K, M>;
    //flatMap<M>(mapper: (value: V, key: K, iter: this) => Funkadelic<M>, context?: any): Collection<K, M>;
    // these seem necessary to push it over the top for memory usage
    //reduce<R>(reducer: (reduction: R, value: V, key: K, iter: this) => R, initialReduction: R, context?: any): R;
    //reduce<R>(reducer: (reduction: V | R, value: V, key: K, iter: this) => R): R;
    toSeq(): Seq<K, V>;
}
interface Seq<K, V> extends Collection<K, V> {
}
interface N1<T> extends Collection<void, T> {
    //map<M>(mapper: (value: T, key: void, iter: this) => M): N1<M>;
    //flatMap<M>(mapper: (value: T, key: void, iter: this) => Funkadelic<M>, context?: any): N1<M>;
}
interface N2<T> extends N1<T> {
    //map<M>(mapper: (value: T, key: void, iter: this) => M): N2<M>;
    //flatMap<M>(mapper: (value: T, key: void, iter: this) => Funkadelic<M>, context?: any): N2<M>;
    toSeq(): N2<T>;
}

Notice that it doesn't even depend on Array or Iterable any more. The current version exhibits the bad behaviour but doesn't run out of memory. If you uncomment the other methods, then you'll get the out-of-memory crash.

[Pajn]

With the workarounds it seems to be the same underlying issue as #15028 and should probably also be fixed by #17433

[sandersn]

@Pajn #15028 has to do with type aliases getting flattened into a single giant type. But immutable uses interfaces everywhere. So I don't think these have the same root cause.

[Pajn]

@sandersn You are right, I'm sorry. I only saw this linked #17097 (comment) and wrongfully thought that the workaround in immutable-js also involved changing type to interface.

[sandersn]

#17947 fixes this oomemory crash. The PR for immutable is still needed to fix the errors uncovered by 2.4, except for the toSeq: any change that works around the crash.