71956250dd
Incremental compilation allows for the output state of one compilation to be reused as input to the next compilation. This involves retaining references to instances from prior compilations, which must be done carefully to avoid memory leaks. This commit fixes such a leak with a complicated retention chain: * `TrackedIncrementalBuildStrategy` unnecessarily hangs on to the previous `IncrementalDriver` (state of the previous compilation) once the current compilation completes. In general this is unnecessary, but should be safe as long as the chain only goes back one level - if the `IncrementalDriver` doesn't retain any previous `TrackedIncrementalBuildStrategy` instances. However, this does happen: * `NgCompiler` indirectly causes retention of previous `NgCompiler` instances (and thus previous `TrackedIncrementalBuildStrategy` instances) through accidental capture of the `this` context in a closure created in its constructor. This closure is wrapped in a `ts.ModuleResolutionCache` used to create a `ModuleResolver` class, which is passed to the program's `TraitCompiler` on construction. * The `IncrementalDriver` retains a reference to the `TraitCompiler` of the previous compilation, completing the reference chain. The final retention chain thus looks like: * `TrackedIncrementalBuildStrategy` of current program * `.previous`: `IncrementalDriver` of previous program * `.lastGood.traitCompiler`: `TraitCompiler` * `.handlers[..].moduleResolver.moduleResolutionCache`: cache * (via `getCanonicalFileName` closure): `NgCompiler` * `.incrementalStrategy`: `TrackedIncrementalBuildStrategy` of previous program. The closure link is the "real" leak here. `NgCompiler` is creating a closure for `getCanonicalFileName`, delegating to its `this.adapter.getCanonicalFileName`, for the purposes of creating a `ts.ModuleResolutionCache`. The fact that the closure references `NgCompiler` thus eventually causes previous `NgCompiler` iterations to be retained. This is also potentially problematic due to the shared nature of `ts.ModuleResolutionCache`, which is potentially retained across multiple compilations intentionally. This commit fixes the first two links in the retention chain: the build strategy is patched to not retain a `previous` pointer, and the `NgCompiler` is patched to not create a closure in the first place, but instead pass a bound function. This ensures that the `NgCompiler` does not retain previous instances of itself in the first place, even if the build strategy does end up retaining the previous incremental state unnecessarily. The third link (`IncrementalDriver` unnecessarily retaining the whole `TraitCompiler`) is not addressed in this commit as it's a more architectural problem that will require some refactoring. However, the leak potential of this retention is eliminated thanks to fixing the first two issues. PR Close #37835 |
||
|---|---|---|
| .. | ||
| animations | ||
| bazel | ||
| benchpress | ||
| common | ||
| compiler | ||
| compiler-cli | ||
| core | ||
| docs | ||
| elements | ||
| examples | ||
| forms | ||
| language-service | ||
| localize | ||
| misc/angular-in-memory-web-api | ||
| platform-browser | ||
| platform-browser-dynamic | ||
| platform-server | ||
| platform-webworker | ||
| platform-webworker-dynamic | ||
| private/testing | ||
| router | ||
| service-worker | ||
| upgrade | ||
| zone.js | ||
| BUILD.bazel | ||
| README.md | ||
| circular-deps-test.conf.js | ||
| empty.ts | ||
| goog.d.ts | ||
| license-banner.txt | ||
| system.d.ts | ||
| tsconfig-build-no-strict.json | ||
| tsconfig-build.json | ||
| tsconfig-test.json | ||
| tsconfig.json | ||
| types.d.ts | ||
README.md
Angular
The sources for this package are in the main Angular repo. Please file issues and pull requests against that repo.
Usage information and reference details can be found in Angular documentation.
License: MIT