Ivy doesn’t deallocate memory of destroyed components correctly #35148

christianliebel · 2020-02-04T22:58:59Z

🐞 bug report

Affected Package

The issue is caused by package @angular/core@9.0.0-rc.14, earlier versions probably as well.

Is this a regression?

This issue does not occur in Angular 8 + View Engine.

Description

Ivy does not seem to correctly deallocate memory of destroyed components in all cases. We’ve noticed an issue that when navigating away from a route, at least some of the loaded components are getting destroyed but not deallocated and garbage collected. (The issue might not be restricted to routing.)

The problem is that unnecessary memory is not deallocated, which might lead to problems on mobile and other low-memory devices and might also have security implications (e.g. when sensitive state remains in memory, even after a user has logged out).

🔬 Minimal Reproduction

Here is a minimal repo of the problem. It’s a plain Angular CLI application with three routes and four components:

/#/route1 (Route1Component) includes the ContentComponent as a child that loads the contents of a large file retrieved via the network into a field of its class during ngOnInit, consuming some memory. This component logs to the console when it’s being initialized or destroyed.
/#/route2 (Route2Component) and route3 (Route3Component) don’t include this component.

Repro steps:

git clone https://github.com/thinktecture-labs/ivy-mem-leak.git
cd ivy-mem-leak
npm i
npm start

Open http://localhost:4200/#/route3
Open Chrome dev tools > Memory
Click 🔴 Take Heap Snapshot
Open http://localhost:4200/#/route2
Take a snapshot (size should stay roughly the same)
Open http://localhost:4200/#/route1, wait until the large file has been downloaded (check the Network tab)
Take a snapshot (size should be larger than before)
Open http://localhost:4200/#/route2
Take a snapshot (size should not significantly change, even though the ContentComponent was destroyed, check the Console tab)

Stop ng serve and compare this with the behavior of Angular 8:

git checkout ng8
npm i
npm start

Click 🚫 Clear All Profiles
Open http://localhost:4200/#/route3
Take a snapshot
Open http://localhost:4200/#/route2
Take a snapshot (size should stay roughly the same)
Open http://localhost:4200/#/route1
Take a snapshot (should be larger than before)
Open http://localhost:4200/#/route2
Take a snapshot (should be similar to the first two snapshots again)

🔥 Exception or Error

The memory of route1’s components doesn’t seem to be correctly deallocated when leaving route1 for route2 on Angular 9/Ivy:

Angular 9/Ivy	Angular 8/View Engine

As per DevTools, (at least) the component instance of the ContentComponent seems to be retained by a contextLView array even after it has been destroyed:

Is this behavior intended or is this a bug?

Researched by @ManuelRauber, @thomashilzendegen and me.

🌍 Your Environment

Angular Version:


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


Angular CLI: 9.0.0-rc.12
Node: 12.14.1
OS: darwin x64

Angular: 9.0.0-rc.14
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router
Ivy Workspace: Yes

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.900.0-rc.12
@angular-devkit/build-angular     0.900.0-rc.12
@angular-devkit/build-optimizer   0.900.0-rc.12
@angular-devkit/build-webpack     0.900.0-rc.12
@angular-devkit/core              9.0.0-rc.12
@angular-devkit/schematics        9.0.0-rc.12
@angular/cli                      9.0.0-rc.12
@ngtools/webpack                  9.0.0-rc.12
@schematics/angular               9.0.0-rc.12
@schematics/update                0.900.0-rc.12
rxjs                              6.5.4
typescript                        3.7.5
webpack                           4.41.2

Anything else relevant?

—

The text was updated successfully, but these errors were encountered:

mhevery · 2020-02-05T04:36:11Z

Kudos for such a well documented repro steps. I wish more people would provide examples such as these.

It looks to me that master is also on Ivy and when I try to reproduce the working example it also retains on master could you please fix that?

mhevery · 2020-02-05T05:16:43Z

OK, I was able to find a root cause and will work on a fix.

Root cause is that for perf reasons we cache LFrame so that we don't have to allocate it all the time. To be extra fast we clear the LFrame on enter rather that on leave. However it does mean that the deepest LFrame will retain objects until the depth matches again.

The fix is to simply clear the LFrame on leave rather then on enter

thomashilzendegen · 2020-02-05T05:33:10Z

@mhevery Thanks for your support. I have to add something:

We used @angular-devkit/build-angular version 0.900.0-rc.12 (as seen in the CLI version output). When I switched to the recent version (0.900.0-rc.14) I got a slightly better result. When the depth matches between routes the cleanup works as intended, but when I navigate to the root route (e.g. by removing route1) the allocated components stay in memory.

Root cause is that for perf reasons we cache `LFrame` so that we don't have to allocate it all the time. To be extra fast we clear the `LFrame` on `enterView()` rather that on `leaveView()`. The implication of this strategy is that the deepest `LFrame` will retain objects until the `LFrame` allocation depth matches the deepest object. The fix is to simply clear the `LFrame` on `leaveView()` rather then on `enterView()` Fix angular#35148

christianliebel · 2020-02-05T07:04:30Z

It looks to me that master is also on Ivy and when I try to reproduce the working example it also retains on master could you please fix that?

@mhevery In the repro, the master branch is Angular 9/Ivy and the ng8 branch is Angular 8/View Engine. As you’ve provided a potential fix, I guess we don't have to update the repro repo?

mhevery · 2020-02-06T05:01:41Z

@mhevery In the repro, the master branch is Angular 9/Ivy and the ng8 branch is Angular 8/View Engine. As you’ve provided a potential fix, I guess we don't have to update the repro repo?

no need to do anything.

Root cause is that for perf reasons we cache `LFrame` so that we don't have to allocate it all the time. To be extra fast we clear the `LFrame` on `enterView()` rather that on `leaveView()`. The implication of this strategy is that the deepest `LFrame` will retain objects until the `LFrame` allocation depth matches the deepest object. The fix is to simply clear the `LFrame` on `leaveView()` rather then on `enterView()` Fix angular#35148

Root cause is that for perf reasons we cache `LFrame` so that we don't have to allocate it all the time. To be extra fast we clear the `LFrame` on `enterView()` rather that on `leaveView()`. The implication of this strategy is that the deepest `LFrame` will retain objects until the `LFrame` allocation depth matches the deepest object. The fix is to simply clear the `LFrame` on `leaveView()` rather then on `enterView()` Fix #35148 PR Close #35156

…35156) Root cause is that for perf reasons we cache `LFrame` so that we don't have to allocate it all the time. To be extra fast we clear the `LFrame` on `enterView()` rather that on `leaveView()`. The implication of this strategy is that the deepest `LFrame` will retain objects until the `LFrame` allocation depth matches the deepest object. The fix is to simply clear the `LFrame` on `leaveView()` rather then on `enterView()` Fix angular#35148 PR Close angular#35156

angular-automatic-lock-bot · 2020-03-16T16:09:06Z

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}

AndrewKushnir added the comp: ivy label Feb 4, 2020

ngbot bot added this to the needsTriage milestone Feb 4, 2020

AndrewKushnir added the area: core Issues related to the framework runtime label Feb 4, 2020

AndrewKushnir modified the milestones: needsTriage, v9-candidates Feb 5, 2020

mhevery mentioned this issue Feb 5, 2020

fix(ivy): LFrame needs to release memory on leaveView() #35156

Closed

14 tasks

Achilles1515 mentioned this issue Feb 5, 2020

Ivy is leaking memory #35164

Closed

AndrewKushnir assigned mhevery Feb 5, 2020

AndrewKushnir added state: has PR type: bug/fix labels Feb 5, 2020

manklu mentioned this issue Feb 5, 2020

datepicker memory leak angular/components#17896

Closed

alxhub closed this as completed in b9b512f Feb 14, 2020

JiaLiPassion mentioned this issue Feb 20, 2020

Ivy doesn't clear the component after the component is destroyed. #35575

Closed

angular-automatic-lock-bot bot locked and limited conversation to collaborators Mar 16, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Ivy doesn’t deallocate memory of destroyed components correctly #35148

Ivy doesn’t deallocate memory of destroyed components correctly #35148

christianliebel commented Feb 4, 2020

mhevery commented Feb 5, 2020

mhevery commented Feb 5, 2020

thomashilzendegen commented Feb 5, 2020

christianliebel commented Feb 5, 2020

mhevery commented Feb 6, 2020

angular-automatic-lock-bot bot commented Mar 16, 2020

Ivy doesn’t deallocate memory of destroyed components correctly #35148

Ivy doesn’t deallocate memory of destroyed components correctly #35148

Comments

christianliebel commented Feb 4, 2020

🐞 bug report

Affected Package

Is this a regression?

Description

🔬 Minimal Reproduction

🔥 Exception or Error

🌍 Your Environment

mhevery commented Feb 5, 2020

mhevery commented Feb 5, 2020

thomashilzendegen commented Feb 5, 2020

christianliebel commented Feb 5, 2020

mhevery commented Feb 6, 2020

angular-automatic-lock-bot bot commented Mar 16, 2020