[lit-html] Memory/Handlers Leak Issues: Rendering Tree of CustomElement using only lit-html, Regression?

[fopsdev]

Hi there

I'm rendering trees of custom elements which itself render themself using lit-html.

Simple repro here: https://github.com/fopsdev/OvlReproMemoryLeak

Please open up devtools when you check out the repro.

• Force a GC (Garbage Collect)
• Check the handlers
• Toggle Comp1 to make it visible
• Force a GC
• Check the handlers
• Toggle Comp1 to make it disappear
• Force a GC -> Handlers doesn't decrease... :(

It works as expected with lit-html 1.1.2

[sorvell]

Here's a playground made from the repo, and running outside the playground here.

Does this reproduce the issue? If so, can you give more explicit step-by-step instructions for how to reproduce it?

Force a GC (Garbage Collect)

This can be done in the Memory tab by click the trash can icon.

Check the handlers

What does this mean?

Thanks.

[jridgewell]

The issue is the global TreeWalker, which holds onto our template elements during Template's constructor and TemplateInstance's _clone. We need to reset the walker.currentNode to the global document to ensure the fragments are not leaked. The not-so-bad part is that only one tree could be leaked at a time, and it'll only leak until the next time something is _cloned.

[fopsdev]

@jridgewell Thanks for catching up on this. This thing drove me close to crazy since i didn't had much experience hunting memory leaks. @sorvell With Handlers/handlers i mean the Nr. of handlers in the Performance Monitor inside Chrome Devtools Btw. the playground doesn't work here (currently?)

[justinfagnani]

Thanks for looking into this @jridgewell !

The one thing I wonder about, if the global tree walker is the cause, is how that would show up as a leak that's noticeable. Is it just that one tree has some handlers and we expected them all to be release after GC, or was @fopsdev seeing a continuous increase in objects/memory?

[sorvell]

Here's what I see when testing the playground (look like the stand alone link is not stable so I pop the iframe into a new tab to test). The downward spike at the end corresponded to pressing the garbage collect button in the dev tools. This seems to indicate that this exact repro is not demonstrating a problematic leak that could grow in an unbounded way.

[jridgewell]

It shouldn't be unbounded, only a single detached DOM tree can be held by the walker at a time. So it'll be whatever was last instantiated into the document with _clone (or whatever was last invoked with html tag if nothing has been inserted into DOM).

[fopsdev]

thanks so far for the insights fyi: i'll spend some time with this issue most probably on sunday

[fopsdev]

Hi again

Had some time already to check this out :)

Having those retainers is really adding up in my full blown framework.

I've changed the repro so it acts closer to my framework: https://user-images.githubusercontent.com/5448300/175766710-9ff07375-5dda-485a-a012-cdf4095a656a.mp4

as i said with lit-html 1.1.2 it works: https://user-images.githubusercontent.com/5448300/175766863-139f76bb-6d5a-465d-975a-ff8ba8ad6d95.mp4

hope that helps

[AndrewJakubowicz]

This issue may be resolved by https://github.com/lit/lit/pull/3888. The tree walker no longer holds onto the last DOM tree.

Is your issue resolved with lit-html@2.7.4? Thank you!