Re: [w3ctag/design-reviews] JavaScript WeakRefs (#321)

A few notes here:

* The explainer doesn't seem to explain what a FinalizationGroup is.  It just sort of starts talking about what you can do with it as though the reader has already heard of it.  It seems like something should introduce it and say what it is first.  (Enough to give somebody a mental answer to the questions:  what is a finalization group?  What is it a group of?)  (I'd like to have another, more careful, read through this once that's clearer, because then I think I'll be able to understand the explainer better.)
* In the note of caution about weak refs, I think there are some additional things that might (or might not) be worth saying:
  * another (common) source of variability is that other variable factors might cause an object to be retained for an unexpected amount of time (e.g., whether the user used a particular piece of functionality might affect the lifetime of an object only peripherally related to that functionality)
  * an additional problem that's distinct from sources of variability is that causing user-visible effects from a destructor causes memory management bugs to turn into user-facing bugs (e.g., saving something to disk in a destructor means that a memory leak can cause the data not to be saved).  (That said, the behavior that finalizers don't run on tab close or process exit means people aren't likely to do this sort of thing.)
* That said, I think the TAG Design Principles recommendation against exposing garbage collection is *also* (maybe but maybe not primarily) about not *accidentally* exposing garbage collection, e.g., by having a method that returns the same object until a GC happens, and then starts returning a different object, or null.  In particular, I think it's more likely for authors to write code that depends on GC timing in bad ways if they're using an API that isn't obviously related to GC timing, and if such APIs are randomly scattered throughout the platform.
* Another concern that I'd like to understand the tradeoffs of:  Can finalization actually entirely prevent garbage collection in some cases?  I think it could with something like Gecko's cycle collector.  I'm not sure what the state of the art is these days for expressing ownership across processes -- but it seems like the use of finalization to avoid memory leaks for cross-worker proxies might fail to produce the expected results with some existing browser memory management code, e.g., if the things that the finalization does represent ownership edges that are unknown to that memory management.  (This would imply that it might be better to encourage people to find other ownership models that don't have this problem.)  Or are these proxy libraries careful to allow ownership edges to exist only in one direction so that this problem is avoided.
  * (Given the above, both the "releasing external resources" example and the "cross-worker proxies" examples make me pretty nervous -- but this is also based on a pretty quick skim of the explainer and not a thorough read through.)
  * (I'd also like to dig in more closely into how similar this is to the behavior of the existing DOM APIs that are mentioned in the "Iterable WeakMaps" section.)
* The statement near the end that "To avoid leaking, cycles across isolated heaps must be explicitly broken." -- I'm curious to what extent this depends on what is or isn't an isolated heap (and how that various across browsers) -- in particular, does this risk more interop problems resulting from browsers having different ownership edges in their internal code (i.e., DOM API implementation) and different strategies (e.g., cycle collection) for dealing with those edges?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/321#issuecomment-494464761