On 11/06/2013 07:37 PM, K. Gadd 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?)

This is a false dichotomy. At the extreme, we could simply ship a new
builtin resource manager which has it's own GC behaviour that we can
expose at will. Given that the sorts of resources that people want to
use the memory GC to manage generally have very different cost and
volume tradeoffs than memory [1], this is actually much more reasonable
than it sounds.

The real problem with weak things is that they do have a performance
impact on the GC, even when not used. Missing weak-maps can at least be
worked around; a slow environment cannot.

-Terrence

1 -
http://www.mail-archive.com/[email protected]/msg00572.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
>>
>>
> 
> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>

On 11/06/2013 07:37 PM, K. Gadd wrote:
> 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.

This is a false dichotomy. At the extreme, we could simply ship a new
builtin resource manager which has it's own GC behaviour that we can
expose at will. Given that the sorts of resources that people want to
use the memory GC to manage generally have very different cost and
volume tradeoffs than memory [1], this is actually much more reasonable
than it sounds.

The real problem with weak things is that they do have a performance
impact on the GC, even when not used. Missing weak-maps can at least be
worked around; a slow environment cannot.

[1]: http://www.mail-archive.com/[email protected]/msg00572.html