-
Notifications
You must be signed in to change notification settings - Fork 47k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[react-core] Clear more properties in detachFiber #16807
Conversation
I think @sebmarkbage's point in #16115 and later #16087 is that we shouldn't play whack-a-mole with trying to clear as much as we can since it has a cost, and often masks the actual underlying issues. For each field clearing which "helps" we need to find a minimal reproducing case that demonstrates a leak. |
In particular, the question would be, this fiber itself has been deleted. So if it’s still retain, what is holding onto to it? However in this case we actually have the very answer to that question in the comment above in the code. It’s an architectural quirks that leaves this node alive for a bit longer so we clear it. I believe we actually do have a way to clear the right parent now so we might be able to do that instead. |
@@ -903,13 +904,14 @@ function detachFiber(current: Fiber) { | |||
current.memoizedState = null; | |||
current.updateQueue = null; | |||
current.dependencies = null; | |||
const alternate = current.alternate; | |||
current.sibling = null; | |||
current.alternate = null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this shouldn’t matter to set which I guess is why the code was structured that way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not needed but it reduces the amount of code quite a bit by re-using the function (which should be hot). I can go back to the previous way if you feel it's better.
@gaearon I'd also not play whack-a-mole, but as per Sebastian's above comment, the reason we have to do this to begin with is because of the architectural quirks. If we have a better solution, then I'm all ears. :)
@sebmarkbage What would that be? That sounds like a better approach. |
When we add deleted fibers to the effect list. We know their parent’s work in progress. If we set the |
@sebmarkbage Makes sense. Shall we close this PR in favor of that approach? We can roll with this change until we land that change as a follow up. |
Yea let’s land this first in case that other approach doesn’t work. |
This PR aims at tackling some potentially retained memory after a fiber gets detached. To do this, we clear down more fields on the fiber to be
null
indetachFiber
.