On Tue, Apr 10, 2012 at 10:09 AM, Jonathan S. Shapiro <[email protected]>wrote: > > Consider any reasonably large GUI application -- a word-processor, >> computer game, or a 3d graphics modeling program. There is no acceptable >> time to stop the world because one can't predict when the user will >> interact next. Moving most of the data out of the view of the GC is a >> solution, but then we're right back to non-safety.... >> > So I agree that the behavior you describe exists, but I do *not* agree > that it is any sort of impediment to use. The occasional, rare, 20ms pause > in an application like this just isn't a big deal >
..either our experiences or our expectations are dramatically different here. I have yet to see a collector that has a global-stop shorter than several **seconds** on a 1GB heap. IMO, we are still writing these apps (and kernels) in C/C++ with manual-memory-management in large part because the pauses are unacceptable. Our server architectures are suffering, and we're being forced to write all but one final tier in C/C++ because cumulative GC pauses kill. Even in the final tier, where we allow GC, we have to be extra careful about heap-sizes because of the dramatically horiffic effects of GC pauses on end-user latency. To believe that GC pauses are "generally not that big of a deal" IMO, is incredibly naive. They are a huge and constant deal in real systems. In the real world, we are constantly being forced to use C++ as an implementation language because of the need to avoid GC pauses. Either that, or we are producing products with sub-standard end-user latency, because we can't eliminate the pauses and are unwilling to use C/C++. This problem is as large or larger than the modularity problem. > The same lack of forgiveness is present in threaded web applications. >> There is normally no time that all threads are simultaneously in a pausable >> activity. >> > A general stop isn't actually required. What's required is for all threads > to enter a new allocation regime before the GC can start. So basically, > you're complaining that the existing GCs are excessively naive and > therefore aren't meeting your needs. Where concurrent programs are > concerned, I tend to agree. > I don't see the distinction for concurrent programs. What non-concurrent program GC has no unpredictable world-stop? The only one I can think of is refcounted (i.e. Python if you turn off the cycle-finder GC). We are naive in not rejecting stop-the-world entirely. It should have been declared a transitory dead-end long ago and fixed. > So what should we *do* about it? > We should reject stop-the-world in our collectors. We should produce mainstream royalty-free x86 runtimes for JVM and CIL that have no world-stop. Looks like Azul may have a commercial JVM with no world-stop. We need tech like this to be 'standard'. We should admit these runtimes are not viable C/C++ alternatives for many applications until we eliminate stop-the-world (and fix modularity). > But that's *exactly* the false dichotomy that the PL world lives in. You >> assume that the only alternative is manual memory management. The thing is: >> you are mistaken. There are two other, very useful, alternatives: >> > > 1. Language support for unboxing, which reduces the number of heap > allocations and permits stack allocation > 2. First-class regions, which permit swathes of objects to be > eliminated simultaneously. > > I see no way to write 'real' apps (a game, word processor dom, web >> browser dom, 3d modeler, caching webserver) without heap mutability, and no >> way to provide typesafe heap mutability without GC. >> > But the argument here isn't about removing GC. It's about combining GC > with other *safe* techniques so that (a) the load on the GC is reduced, > and (b) the triggering of GC can be predicted, and (c) the triggering of > major collections can be avoided > Once it is admitted that stopping-the-world is unacceptable, then "reducing pauses" is not interesting --- because it still does not stop the pause. Once we have pause-free GC, then these techniques become what they should be, methods to increase GC efficiency and throughput... Using them with stop-the-world collectors is like trying to use band-aids to triage a multiple-stab-wound victim. They are too little too late. In reality this doesn't even happen, because we have written the app in C/C++ long before this situation could occur. > In the absense of that, I'm very happy with the direction of the CIL >> design (relative to JVM or those before it) because value-type-structs and >> parametric-type-instantiation off us practical ways to reduce tracable >> pointers and thus pressure on the GC. >> > Yes and no. The value types in CIL remain second class, the absence of a > fixed-length array type is crippling to some very important cases, and the > atomicity rules in the presence of concurrency defeat a whole bunch of > inlining options. > I'm interested to know more about this. Is there something written on it? > > I don't like stop-the-world collectors either, but that >> "unpredictably" word in your sentence is critical. The only collectors I >> know of that are really unpredictable in this way are collectors for >> concurrent programs that require a universal thread rendezvous. >> >> I do not understand the significance of your observation. AFAIK, every >> currently shipping software collector, for every language system, requires >> an unpredictable world-stop. If I am mis-informed, please point me to one >> that does not. >> > As far as I know, there are *no* shipping collectors whose GC trigger > conditions are unpredictable. In every case, GC is an optional side effect > of allocation. The conclusion, then, is that we need the ability to > construct allocation-free subprograms. > Interesting. I don't see how to solve real-world problems with allocation-free subprograms. Such as extending an HTML DOM in response to user-input, or moving 3d polygons through an octree (which requires polygon subdivision and tree splitting). C/C++ programs don't solve these problems in "allocation free ways", so I don't see why that should be our goal. To me it seems simpler and more straightforward to solve the direct problem (GC pauses). Then we can shift from unsafe-to-safe programming without debating whether a "pause is too big or not". After we have a zero-pause runtime, we can spend time and research on alternative techniques such as regions and advancements to value-types to relieve pressure on the GC system. Applying them will become a tradeoff of efficiency vs programmer time. This is an tradeoff we are very good at dealing with. GC pauses are not something we can "tradeoff" they are simply an unacceptable wall that forces us back to C/C++.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
