On Fri, Oct 20, 2017 at 10:52 AM, Filip Pizlo <fpi...@apple.com> wrote:
> > > On Oct 20, 2017, at 10:29 AM, Mark Miller <erig...@gmail.com> wrote: > > 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. > > > Being collected when it shouldn’t have been? Like a dangling reference. > The game theory of security exploits forces implementations to keep things > alive longer, not shorter. > Not what I meant. Being collected when it should not be would clearly violate the spec. Rather, the weakref spec never guarantees that anything is collected. Any program whose correct behavior ever relies on anything being observably collected is an incorrect program. When run on a different correct implementation --- one on which those objects never get observably collected --- it will misbehave. > > 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. > > > Java had weak refs and multiple different implementations. My claim, as > someone who implemented lots of weird GC algorithms in Java, is that I > don’t know of a case where different weak ref semantics breaks something. > The only time that getting it wrong ever had an observably bad effect is > when you break weak refs or finalizers so badly that they never get cleared > or called, and then some resource has an unbounded leak. This usually > results in not being able to run any benchmarks that have weak references > or finalizers, so you fix those bugs pretty quickly. > > Here are the motivations: > - Competitive perf motivates GC authors to try to free things as soon as > possible. Smaller heaps mean more speed. Some benchmarks won’t run to > completion if you aren’t aggressive enough. > This causes only a tendency to collect more as a quality-of-implementation issue. And even for that, it is at best a statistical issue. There is never a guarantee that anything in particular will get collected. - The need to avoid dangling references forces us to keep alive at least > what we need to, and sometimes a bit more. > "Need to" in the sense of strongly referenced, absolutely. Any implementation that fails to do so seriously violates the spec and more. There is no controversy on this point. The concern is "need to" in the sense that a given program points at something only weakly at t1, fetches is at t2 and finds it still there and comes to count on that behavior. A different correct implementation might cause this same program to find that the object has been collected before t2, causing this buggy program to break. > > I guess a program could rely on the weak references actually being strong > in some implementation. I haven’t heard of Java programs ever doing that. > It’s unlikely to happen because the major implementations will try to clear > weak refs as aggressively as they can to compete on benchmarks. > > Perhaps part of the problem here is that we’re assuming that GC is already > not observable. It’s totally observable. We have to fix bugs sometimes > because the GC didn’t free something it should have, and the memory > footprint of an app balloons so much that it crashes. Also, people obsess > over GC perf and GC pauses exactly because they observe them. Considering > all of the existing ways that GCs are observable, I don’t think that weak > refs change the game. > I can only see this argument becoming solid if we were willing to consider obligating the platform to do accurate gc, rather than conservative gc. 1) no one is willing to advocate that, including me. 2) Even if we were, the timing would still cause all the same issues. > I think there are features of the web platform that are significantly more > likely to create incompatibilities than this issue, and you seem to agree: > > > 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 > boundaries). > > 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 > admitted SAB. > > Yes, I do agree with that. I am making a comparative argument, not an argument about absolutes. > > 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 > non-determinism specifically. > > > Can you clarify what you think this means for weak refs? > I will in that other thread ;) > > -Filip > > > > > > On Fri, Oct 20, 2017 at 9:54 AM, Dean Tribble <trib...@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 >> further. >> >> On Fri, Oct 20, 2017 at 7:54 AM, Filip Pizlo <fpi...@apple.com> wrote: >> >>> >>> >>> > On Oct 20, 2017, at 7:45 AM, Mike Samuel <mikesam...@gmail.com> wrote: >>> > >>> >> On Fri, Oct 20, 2017 at 10:33 AM, Filip Pizlo <fpi...@apple.com> >>> wrote: >>> >> For what it’s worth, I have never agreed with this policy. This >>> policy seems >>> >> 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 >>> to >>> >> work well with existing code. It seems like we are using non-problems >>> to >>> >> 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 >>> fine-grained >>> >> 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. >>> >>> -Filip >>> >>> _______________________________________________ >>> es-discuss mailing list >>> es-discuss@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > > -- > Cheers, > --MarkM > > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
