> 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. > 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. - The need to avoid dangling references forces us to keep alive at least what we need to, and sometimes a bit more. 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 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. > > 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? -Filip > > > > On Fri, Oct 20, 2017 at 9:54 AM, Dean Tribble <trib...@e-dean.com > <mailto: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 > <mailto:fpi...@apple.com>> wrote: > > > > On Oct 20, 2017, at 7:45 AM, Mike Samuel <mikesam...@gmail.com > > <mailto:mikesam...@gmail.com>> wrote: > > > >> On Fri, Oct 20, 2017 at 10:33 AM, Filip Pizlo <fpi...@apple.com > >> <mailto: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 <mailto:es-discuss@mozilla.org> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss> > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org <mailto:es-discuss@mozilla.org> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss> > > > > > -- > Cheers, > --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
