On Wed, Nov 6, 2013 at 7:37 PM, K. Gadd <kg at luminance.org> wrote:
> Generally speaking, all the discussions on this list about WRs so far have
> not suggested that there is any way to introduce WeakRefs without making GC
> behavior observable in some fashion. WeakRefs functionally make GC
> observable because when you try to get at the target of the weakref, you
> either get it or you don't. Once you introduce the ability to get back
> 'null' when asking for the target of a WR (or any similar failure case),
> you can use that to determine things about GC behavior.
>
> If you somehow eliminate this weakness, WRs no longer solve the problems
> they are intended to solve. Or at the least, they solve only a small
> reduced subset of the problems solved in real software via the use of weak
> references. Being able to access the target of the WR (and have this
> operation fail) is core to their value (even if finalization notifications
> are also used quite often).
>
> I've already argued in the past about why weak references are important,
> and why not having solutions for those problems will kneecap the
> development of web applications by either preventing certain types of
> software from running in the browser, or forcing implementers to write
> their own GCs (or entire runtime environments) inside the browser, as is
> done with environments like emscripten and native client. Once that becomes
> the solution, the ES spec is irrelevant for those applications because they
> have had to abandon the language. While the risk of something like this
> happening is still relatively low, the risk increases over time as more
> people begin seriously considering solutions like emscripten and nacl -
> we're starting to see companies ship real products using them already. If
> this spreads to popular reusable libraries (physics libraries, rendering
> libraries, etc), there's a risk that those libraries will pull new
> applications out of the ES realm because it's not possible to use those
> libraries without abandoning ES in favor of a custom GC/runtime environment.
>
> Based on the conversations thus far, a choice just has to be made between
> the two downsides: exposing some amount of GC internals, or making it
> impossible to write some subset of applications in ES. It's possible that
> exposing GC semantics has such catastrophic security consequences that
> ruling those applications out is merited. It's also possible that
> workarounds can be applied to reduce the harm of GC visibility (I think in
> the past someone - maybe Mark? - suggested that disabling cross-realm WRs
> would mitigate the damage considerably?)
>
Yes, that's the idea.
https://mail.mozilla.org/pipermail/es-discuss/2013-January/028542.html
>
> On Wed, Nov 6, 2013 at 3:23 PM, Oliver Hunt <oliver at apple.com> wrote:
>
>> On Nov 6, 2013, at 3:14 PM, Rick Waldron <waldron.rick at gmail.com> wrote:
>>
>>
>>
>>
>> On Wed, Nov 6, 2013 at 2:15 PM, Domenic Denicola <
>> domenic at domenicdenicola.com> wrote:
>>
>>> Thanks Mark for the education, especially on the pre- vs. post-morterm
>>> finalization distinction. I don't think I was specifically advocating for
>>> pre-mortem in my OP, since I didn't really understand the difference :P.
>>> Post-mortem finalization sounds quite reasonable. What do people think of
>>> introducing it into ECMAScript?
>>>
>>
>> This may be a naïve question, but how would the handler know which
>> object/weakref had been gc'ed?
>>
>> You wouldn’t :)
>>
>> I’m kind of anti-finalisers in JS for all of the reasons people have
>> raised - they are extremely hazardous, expose non-deterministic behaviour,
>> etc
>>
>> Given our general desire to avoid exposing internal GC semantics, and the
>> difficulty in defining observable GC behaviour (I suspect this would be a
>> non-starter in any case), I can’t see any specification that would allow
>> useful finalisers or WeakRefs.
>>
>> If MarkM has an idea for WeakRefs that don’t leak observable GC behaviour
>> i’d love to hear, but in general i’m opposed to both them and finalisers :-/
>>
>> —Oliver
>>
>> Rick
>>
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131106/476e14f4/attachment-0001.html>
forbes at lindesay.co.uk (2013-11-07T12:56:38.721Z)
Yes, that's the idea.
https://mail.mozilla.org/pipermail/es-discuss/2013-January/028542.html
On Wed, Nov 6, 2013 at 7:37 PM, K. Gadd <kg at luminance.org> wrote: > Generally speaking, all the discussions on this list about WRs so far have > not suggested that there is any way to introduce WeakRefs without making GC > behavior observable in some fashion. WeakRefs functionally make GC > observable because when you try to get at the target of the weakref, you > either get it or you don't. Once you introduce the ability to get back > 'null' when asking for the target of a WR (or any similar failure case), > you can use that to determine things about GC behavior. > > If you somehow eliminate this weakness, WRs no longer solve the problems > they are intended to solve. Or at the least, they solve only a small > reduced subset of the problems solved in real software via the use of weak > references. Being able to access the target of the WR (and have this > operation fail) is core to their value (even if finalization notifications > are also used quite often). > > I've already argued in the past about why weak references are important, > and why not having solutions for those problems will kneecap the > development of web applications by either preventing certain types of > software from running in the browser, or forcing implementers to write > their own GCs (or entire runtime environments) inside the browser, as is > done with environments like emscripten and native client. Once that becomes > the solution, the ES spec is irrelevant for those applications because they > have had to abandon the language. While the risk of something like this > happening is still relatively low, the risk increases over time as more > people begin seriously considering solutions like emscripten and nacl - > we're starting to see companies ship real products using them already. If > this spreads to popular reusable libraries (physics libraries, rendering > libraries, etc), there's a risk that those libraries will pull new > applications out of the ES realm because it's not possible to use those > libraries without abandoning ES in favor of a custom GC/runtime environment. > > Based on the conversations thus far, a choice just has to be made between > the two downsides: exposing some amount of GC internals, or making it > impossible to write some subset of applications in ES. It's possible that > exposing GC semantics has such catastrophic security consequences that > ruling those applications out is merited. It's also possible that > workarounds can be applied to reduce the harm of GC visibility (I think in > the past someone - maybe Mark? - suggested that disabling cross-realm WRs > would mitigate the damage considerably?) > Yes, that's the idea. https://mail.mozilla.org/pipermail/es-discuss/2013-January/028542.html > > On Wed, Nov 6, 2013 at 3:23 PM, Oliver Hunt <oliver at apple.com> wrote: > >> On Nov 6, 2013, at 3:14 PM, Rick Waldron <waldron.rick at gmail.com> wrote: >> >> >> >> >> On Wed, Nov 6, 2013 at 2:15 PM, Domenic Denicola < >> domenic at domenicdenicola.com> wrote: >> >>> Thanks Mark for the education, especially on the pre- vs. post-morterm >>> finalization distinction. I don't think I was specifically advocating for >>> pre-mortem in my OP, since I didn't really understand the difference :P. >>> Post-mortem finalization sounds quite reasonable. What do people think of >>> introducing it into ECMAScript? >>> >> >> This may be a naïve question, but how would the handler know which >> object/weakref had been gc'ed? >> >> You wouldn’t :) >> >> I’m kind of anti-finalisers in JS for all of the reasons people have >> raised - they are extremely hazardous, expose non-deterministic behaviour, >> etc >> >> Given our general desire to avoid exposing internal GC semantics, and the >> difficulty in defining observable GC behaviour (I suspect this would be a >> non-starter in any case), I can’t see any specification that would allow >> useful finalisers or WeakRefs. >> >> If MarkM has an idea for WeakRefs that don’t leak observable GC behaviour >> i’d love to hear, but in general i’m opposed to both them and finalisers :-/ >> >> —Oliver >> >> Rick >> >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131106/476e14f4/attachment-0001.html>