Re: Memory management in features implemented in JS

2014-03-22 Thread K. Gadd
I implied that the popups are using the parent document to communicate with each other (I thought I stated this?). If you retain the parent document after it is closed in order to keep the child documents working, now you have a cycle that requires a cycle collector (parent -> children, children ->

Re: Memory management in features implemented in JS

2014-03-22 Thread Bobby Holley
On Sat, Mar 22, 2014 at 8:26 AM, K. Gadd wrote: > I mentioned self-hosting to illustrate the need for weak references: > It's fine that the JS > environment has no weak reference alternative as long as all the 'hard > stuff' is > written in C++, but it seems as if there are reasons to move and >

Re: Memory management in features implemented in JS

2014-03-22 Thread Jim Blandy
Perhaps in some cases weaker, more manageable mechanisms than full-powered observers and listeners could be sufficient. For example, one approach which gets you the right cleanup behavior without exposing GC, is to have special-case observers which can be easily proven to be safe to drop. For

Re: Memory management in features implemented in JS

2014-03-22 Thread Boris Zbarsky
On 3/23/14 1:38 AM, Jim Blandy wrote: For example, suppose we had: observerService.addSettingObserver(obj, "dirty", true) which promises to set obj's 'dirty' property to true. If obj is collected, this observer can obviously be dropped. How do we know when "obj" is collected? Or put ano

Re: Memory management in features implemented in JS

2014-03-22 Thread Jim Blandy
On 03/19/2014 04:39 PM, Kyle Huey wrote: Short of not implementing things in JS, what ideas do people have for fixing these issues? We have some ideas of how to add helpers to scope these things to the lifetime of the window (perhaps by adding an API that returns a promise that is resolved at in

Re: Memory management in features implemented in JS

2014-03-22 Thread Jim Blandy
On 03/22/2014 10:43 PM, K. Gadd wrote: > I'm confused about how this would work. who's observing what? How can > obj be collected if you're passing it as an argument? This looks like > a synchronous property set passed through an unnecessary intermediary. Sorry, my code example was confusingly in

Re: Memory management in features implemented in JS

2014-03-22 Thread Jim Blandy
On 03/22/2014 10:51 PM, Boris Zbarsky wrote: Or put another way, how does this proposal differ from the already existing ownsWeak argument of nsIObserverService.addObserver that was discussed earlier in this thread? See my slightly longer explanation in the previous message. The advantage over

Re: Memory management in features implemented in JS

2014-03-22 Thread Boris Zbarsky
On 3/23/14 2:21 AM, Jim Blandy wrote: See my slightly longer explanation in the previous message. The advantage over passing true for ownsWeak is that my proposed API is completely deterministic. I'm not sure I follow The current setup in the observer service is also completely determinis