> On Jul 6, 2014, at 9:30 AM, "Mark S. Miller" <erights at google.com> wrote:
> 
>> On Sun, Jul 6, 2014 at 7:47 AM, Katelyn Gadd <kg at luminance.org> wrote:
>> There are some fairly recent es-discuss threads about weak references.
>> I don't know if there is a consensus yet (it is very hard to tell) but
>> some people like Brendan are on record that there are real use cases
>> that require them. I've been pushing hard for them, along with the
>> author of embind. The question is mostly whether solving those
>> problems is worth the cost of exposing GC to content JS (though, if
>> memory serves, there was a claim in one of the discussion threads that
>> you can implement weakrefs without exposing GC - I'm not sure if that
>> was an 'I've figured it out' statement or just a hypothesis).
> 
> I would be very curious. It seems impossible by definition. Could you (or anyone) please try to find this? Thanks.
> 
> What I have claimed is that we can isolate the communications channel that this provides in ways that make it a reasonable (IMO) security risk. Perhaps this is what you are thinking of?

I've read this exchange and might be missing context. I'm intrigued by it and want to know more. 

Is the main opposition to weak references just the security implications of information revealed by GC?  Has anyone quantified how much information is leaked, or proved that this information cannot be obtained through already exposed APIs or language features?  I presume it has something to do with detecting if anyone else has a reference to an object. 

-Filip

>  
>> 
>> At present I don't believe WRs will ever make it onto the open web. It
>> seems like there's a huge amount of resistance to the idea that is
>> never going to go away, so any application that needs them is
>> best-served by an emscripten-style heap and manually implemented
>> collector (boehm, etc). You could probably achieve some sort of
>> compromise by writing your own user-space collector that walks the
>> reachable JS heap if you manage to root your JS objects correctly, but
>> I suspect that would only be viable as a codegen strategy for a
>> compiler targeting JS, not something you'd do by hand when writing JS.
>> 
>> For some WR use cases you can probably do manual refcounting yourself,
>> as long as you do it right - you'd want to replace the actual object
>> references with a lightweight 'handle' object that forwards onto the
>> real instance via a handle lookup, so that you can 'collect' the
>> actual instance without requiring the handles to die.
>> 
>> On Sun, Jul 6, 2014 at 3:17 AM, Till Schneidereit
>> <till at tillschneidereit.net> wrote:
>> > There is an ES7 proposal for weak references[1] that would satisfy your
>> > requirements. However, at least at Mozilla there is very strong opposition
>> > to this from people working on the memory management subsystems (i.e. the GC
>> > and CC). It's not clear to me that their arguments have been defeated and
>> > I'm not aware of any more recent discussions about this topic than those on
>> > Mozilla's platform development mailing list[2][3].
>> >
>> > While I think that weak references are an important feature, I don't think
>> > this particular use case is a good argument for them: in my personal
>> > experience working with and implementing systems like you describe, weak
>> > listeners were eventually deprecated and replaced by forced explicity
>> > unsubscription every time. If a view is destroyed, you really don't want it
>> > to receive any events anymore, regardless of the GC's timing. Now you could
>> > say that in the framework's event dispatching or handling mechanism you can
>> > detect this situation. If so, you can also just unsubscribe a strongly-held
>> > event listener at that point.
>> >
>> >
>> > [1]: http://wiki.ecmascript.org/doku.php?id=strawman:weakreferences
>> > [2]:
>> > https://groups.google.com/forum/#!topic/mozilla.dev.tech.js-engine.internals/V__5zqll3zc
>> > [3]:
>> > https://groups.google.com/forum/#!topic/mozilla.dev.tech.js-engine.internals/9LcqR9m5Mo4
>> >
>> >
>> >
>> > On Sun, Jul 6, 2014 at 7:00 AM, Peter Michaux <petermichaux at gmail.com>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> I've been reading about WeakMap in the draft. To my surprise, it is
>> >> not at all what I thought it would be or what I was hoping to use. At
>> >> least that is my understanding.
>> >>
>> >> My use case is in MV* architectures. With current MV* frameworks, a
>> >> model holds strong references to the views observing that model. If a
>> >> view is removed from the DOM, all other references in the application
>> >> are lost to that view, but the view never stopped observing the model
>> >> object, that strong reference from model to view results in a zombie
>> >> view. Avoiding this means views need to have `destroy` methods that
>> >> unsubscribes the view from the model. It is easy for the application
>> >> programmer to forget to call a view's `destroy` method and the
>> >> application leaks memory. As a result of the leak, the user experience
>> >> and ultimately the reputation of the Web suffers. If a model could
>> >> hold weak references to its observers, this would safeguard against
>> >> accidental and inevitable application programmer forgetfulness.
>> >>
>> >> It appears that WeakMap cannot help solve the current MV* zombie view
>> >> problem. Or did I miss something?
>> >>
>> >> I was expecting WeakMap to hold its values weakly and set them to
>> >> undefined or delete the associated key when the value was garbage
>> >> collected.
>> >>
>> >> Does anything exist or is coming to help solve the zombie problem?
>> >>
>> >> ----
>> >>
>> >> Smalltalk Squeak models use a WeakIdentityKeyDictionary which holds
>> >> its keys weakly. The difference compared with the ECMAScript WeakMap
>> >> is that instances of WeakIdentityKeyDictionary have an iterator so the
>> >> observers can be stored as the keys and still discoverable without
>> >> keeping other strong references. The ECMAScript standard specifically
>> >> disallows in iterator.
>> >>
>> >> Thanks,
>> >> Peter
>> >> _______________________________________________
>> >> es-discuss mailing list
>> >> es-discuss at mozilla.org
>> >> https://mail.mozilla.org/listinfo/es-discuss
>> >
>> >
>> >
>> > _______________________________________________
>> > es-discuss mailing list
>> > es-discuss at mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> 
> -- 
>     Cheers,
>     --MarkM
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140706/4ef31dd6/attachment-0001.html>

I've read this exchange and might be missing context. I'm intrigued by it and want to know more. 

Is the main opposition to weak references just the security implications of information revealed by GC?  Has anyone quantified how much information is leaked, or proved that this information cannot be obtained through already exposed APIs or language features?  I presume it has something to do with detecting if anyone else has a reference to an object.