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

Pre-RFC: Automated GC via WeakRef #8162

Open
runspired opened this issue Sep 2, 2022 · 4 comments
Open

Pre-RFC: Automated GC via WeakRef #8162

runspired opened this issue Sep 2, 2022 · 4 comments

Comments

@runspired
Copy link
Contributor

Now that WeakRef is available in all browsers except Opera, we should explore adding a true GC to EmberData. This would replace the unloadRecord and unloadAll APIs.

The mechanics of this would roughly be

  • we use WeakRef's to hold the reference to the instantiated record, nothing else (would have to work out how this plays with the record=>identifier cache=>identifier maps)
  • records and associated state objects would thus automatically GC when dereferenced by the UI (and be recreated later only if accessed again)
  • we would periodically schedule a sweep (configurable schedule?) (or users could force a sweep). Any dereferenced records without relationships would be expunged from the cache. Any records with relationships would be expunged if all related records were also dereferenced. Any dereferenced records who were only members of async relationships would also be expunged.
@runspired
Copy link
Contributor Author

Even if we don't add this GC we should probably explore a WeakRef mode whereby a user cache implementation could choose to implement GC

@snewcomer
Copy link
Contributor

This seems like a really interesting place to explore and doable?!? Another path could be maintain a strong ref and remove the strong ref when the expiry clocks in.

Also this seems really useful.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/FinalizationRegistry

Any dereferenced records who were only members of async relationships would also be expunged.

Seems like a great idea!

and be recreated later only if accessed again

One question I have is, say for a list view, if 10 out of the 50 items were GC'ed, what is our recovery strategy for those 10? Recreated means "get from API" right?

@BryanCrotaz
Copy link
Contributor

"what is our recovery strategy"

I would say it's the same as though they were never loaded before

@runspired
Copy link
Contributor Author

this would also allow us to detect when a relationship was no longer "active" and return to a "lazy" mode for it once #8806 is completed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: needs champion
Development

No branches or pull requests

3 participants