TS 4.6.2+ JavaScript heap out of memory

[MarcoGlauser]

Bug Report

Moved from #39059 (comment)
Related to google/schema-dts#98

After upgrading from 4.5.5 to 4.6.2 we got the following Stacktrace when trying to build our project:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb0a860 node::Abort() [node]
 2: 0xa1c193 node::FatalError(char const*, char const*) [node]
 3: 0xcf9a6e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
 4: 0xcf9de7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
 5: 0xeb1685  [node]
 6: 0xeb2166  [node]
 7: 0xec068e  [node]
 8: 0xec10d0 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
 9: 0xec404e v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
10: 0xe852c2 v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [node]
11: 0xe7fbdc v8::internal::FactoryBase<v8::internal::Factory>::AllocateRawArray(int, v8::internal::AllocationType) [node]
12: 0xe7fcb5 v8::internal::FactoryBase<v8::internal::Factory>::NewFixedArrayWithFiller(v8::internal::Handle<v8::internal::Map>, int, v8::internal::Handle<v8::internal::Oddball>, v8::internal::AllocationType) [node]
13: 0x10e853e v8::internal::MaybeHandle<v8::internal::OrderedHashMap> v8::internal::OrderedHashTable<v8::internal::OrderedHashMap, 2>::Allocate<v8::internal::Isolate>(v8::internal::Isolate*, int, v8::internal::AllocationType) [node]
14: 0x10e85f3 v8::internal::MaybeHandle<v8::internal::OrderedHashMap> v8::internal::OrderedHashTable<v8::internal::OrderedHashMap, 2>::Rehash<v8::internal::Isolate>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::OrderedHashMap>, int) [node]
15: 0x11f4705 v8::internal::Runtime_MapGrow(int, unsigned long*, v8::internal::Isolate*) [node]
16: 0x15f2d39  [node]
Aborted (core dumped)

Trying different versions, 4.6.1-rc is the last version that works. Any version after, including the nightlies,cannot transpile the project.

🔎 Search Terms

• Maximum call stack size exceeded
• Out of Memory

🕗 Version & Regression Information

• This is a crash
• This changed between versions 4.6.1-rc and 4.6.2

⏯ Playground Link

The playground link is too long to post here, since I can't easily narrow the exact type from this project that is causing the issue.

Minimal reproduction repository

Node Memory Profiles

💻 Code

import { Thing, WithContext, Product} from "schema-dts";

// This line seems to be the culprit
export type ThingWithoutString = Exclude<Thing, string>;

export const addContextToSchema = <T extends ThingWithoutString>(schema: T): WithContext<T> => {
    return {
        '@context': 'https://schema.org',
        ...schema
    };
};

export const product: Product = {
    "@type": "Product",
    "name": "Some Product",
}

addContextToSchema(product)

🙁 Actual behavior

tsc ran out of memory

🙂 Expected behavior

tsc should transpile

[amcasey]

@MarcoGlauser I can't thank you enough for providing a good repro. 👍

[amcasey]

git bisect points to 57bd608 - FYI @ahejlsberg

[amcasey]

Before that commit, tsc runs in ~7 seconds and less than 512 MB. After that commit, it OOMs in ~21 seconds (longer, if you give it more memory).

[amcasey]

Specifically, it seems to have been 2670b26 (one of the squashed commits in #47738).

[ahejlsberg]

Hmm, yeah the re-ordering in that commit ended up affecting situations where we're relating a type parameter to a union type. We used to first try obtaining the constraint of the type parameter and relating that to the union type. Then, if that failed, we'd call getEffectiveConstraintOfIntersection and try relate that to the union type. That got reversed with the re-ordering, and it turns out the type produced by getEffectiveConstraintOfIntersection is very expensive to operate on (it's a union of ~900 intersections). I'll put up a PR to restore the old ordering.

BTW, the types in the repro definitely have the potential to cause trouble. Thing is a discriminated union with ~900 members. Pretty much any relation or transformation involving that type is going to generate lots of work.