Skip to content
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

Prevent memory leaking under MDV polyfill #154

Closed
sjmiles opened this issue May 22, 2013 · 1 comment
Closed

Prevent memory leaking under MDV polyfill #154

sjmiles opened this issue May 22, 2013 · 1 comment
Assignees

Comments

@sjmiles
Copy link
Contributor

sjmiles commented May 22, 2013

In the absence of native Object.observe, MDV must maintain a static list of binding participants. Because there is no discrete disposition step for elements, if a user simply discards all references to a Polymer node, we have no way of unbinding that node, and it is never GC'd.

We plan to employ a scheme whereby MDV bindings on a subtree can be deactivate/reactivated. Deactivation will remove the binding data from MDV static lists and store that data on the node itself. Reactivation will restore that binding data to MDV.

If a node is discarded while deactivated, it can GC appropriately.

The idea is to activate nodes on document insertion, and deactivate them on removal, with the added notion of a 'spin down' time, measured in some small number of microtasks, in which the user can re-insert a node or utilize it's API before it's deactivated after removal.

We also intend to add a facility to control activation imperatively, for non-standard use cases. Of course, the onus will be on the user at this point to ensure proper deactivation before GC can occur.

@ghost ghost assigned sjmiles May 22, 2013
@ghost ghost assigned sorvell Jun 12, 2013
@sorvell
Copy link
Contributor

sorvell commented Jun 12, 2013

Addressed in 5b869b5.

A slightly simpler system was implemented. Binding state is not cached so it's not possible to re-activate bindings after unbinding has occurred. Instead the requirement is that the user must prevent deactivation during the spin down period.

To facilitate this, these public methods have been exposed on polymer elements:

  • asyncUnbindAll: unbind the element after a short period of time.
  • cancelUnbindAll: prevent the element from being unbound if it's been scheduled to be unbound by a call to asyncUnbindAll.

Here's what Polymer does:

  1. at ready time, create bindings and call asyncUnbindAll
  2. at inserted time, call cancelUnbindAll
  3. at removed time, call asyncUnbindAll

The resulting system is mostly transparent and mirrors standard dom behavior. There is one exception: if a user wants a polymer element to remain bound when not in the document, the user must call cancelUnbindAll when the element is created or removed from the document. It's then the user's responsibility to call unbindAll to dispose of the element

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants