erights at gmail.com
Fri Oct 20 17:29:48 UTC 2017
There is a glaring inconsistency in the criteria we use to evaluate these
issues. While we are understandably reluctant to admit more non-determinism
into the platform via weakrefs, we have admitted an astonishingly greater
degree of non-determinism into the platform via "Shared Array Buffers"
(SAB), i.e., shared memory multithreading with data races.
The scenario we legitimately fear for weakrefs: A developer writes code
that is not correct according to the weakref specification but happens to
work on present implementations. Perhaps it relies on something being
collected that is not guaranteed to be collected. Perhaps it relies on
something not being collected that is not guaranteed not to be collected. A
later correct change to an implementation, or another correct
implementation, causes that code to break. The game theory punishes the
correct implementation rather than the incorrect code.
The parallel scenario for data races is clear. And on some measures, the
magnitude of the problem is orders of magnitude larger for SAB because of
* the fine granularity of non-deterministic interleaving (especially if
observable gc interleaving happens only at turn boundaries),
* the greater difficultly of reasoning about memory models vs observable gc
(again, especially if observable gc interleaving happens only at turn
At least we all already understand that the side channel
information-leakage opened up by SAB is orders of magnitude larger than
that opened up by weakrefs, and so this is not generally raised as an
additional argument against weakrefs for a platform that has already
I will start a separate thread on making the computation within an
individual turn more deterministic. SAB aside, the threats to intra-turn
determinism can and should be reduced. All the arguments against
non-determinism in general should be at least as strong against intra-turn
On Fri, Oct 20, 2017 at 9:54 AM, Dean Tribble <tribble at e-dean.com> wrote:
> I do think that we need weak references for all the reasons given in the
> proposal. But indeed non-determinism is a concern. The reference Dominic
> pointed at is one of two primary (areas of) considerations. The other is
> just how many amazing things you can do if turns are deterministic (more
> reliable testing, replay debugging, checkpoint/retry in the event of
> component failure, simpler correctness analysis on code, etc.).
> Exposing non-determinism only at turn boundaries and controlling access to
> the ability to observe GC both help some with the first motivation above
> (and a lot with the second). However, not enough. I'm hoping to make
> another run at weakrefs in November with some changes to help concern #1
> On Fri, Oct 20, 2017 at 7:54 AM, Filip Pizlo <fpizlo at apple.com> wrote:
>> > On Oct 20, 2017, at 7:45 AM, Mike Samuel <mikesamuel at gmail.com> wrote:
>> >> On Fri, Oct 20, 2017 at 10:33 AM, Filip Pizlo <fpizlo at apple.com>
>> >> For what it’s worth, I have never agreed with this policy. This policy
>> >> to be based on feelings not facts.
>> >> I remember implementing real time GCs for Java, which changed GC
>> timing and
>> >> behavior a lot, and having zero problem getting that aspect of the GC
>> >> work well with existing code. It seems like we are using non-problems
>> >> make excuses to avoid supporting something useful.
>> >> In fact, WeakMap is more restrictive constraint on GC algo than weak
>> refs or
>> >> finalization or whatever, since it means that a Siebert-style
>> >> incremental GC with O(1) increments is off the table.
>> > I'm not familiar with Siebert GCs so I apologize if this is beside
>> > your point. My recollection of those discussions was that we
>> > rejected weak refs in favor of ephemerons because weak references are
>> > still prone to uncollectible cycles that involve a weakly referenced
>> > object being used as both a key and a value.
>> It’s better to have both. Some use cases are not covered by WeakMap, as
>> evidenced by the fact that people still ask for weak refs or a gc trigger
>> or notification.
>> es-discuss mailing list
>> es-discuss at mozilla.org
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss