Application stays in memory even after being destroyed

[mcgraphix]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

When the platform is destroyed, the DOM node is removed but the application still exists in memory. This is easily verified by taking a heap snapshot after destruction of the platform.

Expected behavior

When the application is destroyed using PlatformRef.destroy() or even if the DOM node was removed manually, the application should not continue to exist in memory.

Minimal reproduction of the problem with instructions

Here is a simple stackblitz application that illustrates the problem: https://angular-h1zvzr.stackblitz.io/

• Take a heap snapshot and you will see references to ApplicationRef, PlatformRef, and other Angular classes in memory
• Click the "destroy" button. This calls destroy() on the platform ref that was temporarily stored on the window by the default stackblitz angular application. It then deletes the reference off the window.
• Notice the application appears to be gone as the DOM nodes have been removed.
• Take a heap snapshot and the references are still there.

What is the motivation / use case for changing the behavior?

In a portal environment where applications may come and go as the user navigates around, this causes a significant memory leak when the applications are not cleaned up.

Environment

Angular version: 2 - 5


Browser:
- [x] Chrome (desktop) version 63
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [x] Firefox version 56
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX
 
For Tooling issues:
- Node version: 6.11.3 but probably happens regardless  
- Platform:  Mac (but probably any)

Others:

This is related to #13725 but that defect seems to have conflated several different things into one conversation.

[msms007]

any info about when this gets released?

[pkozlowski-opensource]

I can still confirm this issue in Angular v9 running ivy: https://stackblitz.com/edit/angular-8gx4rp?file=src%2Fmain.ts

There is a PR #22238 that correctly identifies TestabilityRegistry as one of the retainers but it might be more to it. We should definitively try to merge #22238 and re-run this scenario to make sure that all is released properly.

[angular-automatic-lock-bot]

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.}