On Fri, Apr 13, 2012 at 1:19 PM, David Jeske <[email protected]> wrote:
> > On Apr 13, 2012 10:10 AM, "Jonathan S. Shapiro" <[email protected]> wrote: > >> 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. > > > > That's backwards. The region and other advances are available to us > today. The pausless collectors are still not understood well enough to be > mainstream yet. > > I'm working on a longer response to some other points, but i think this > divide above deserves some digging into on both sides. Here is my > reasoning. Im very interested to hear yours... > My reasoning is actually very simple. Pauseless GC is important, but there are many other issues that demand our attention if we are going to write high-performance systems. Regions turn out to be among them, and we know - today - how to do them. When I wrote the note above, I wasn't aware of how far C4 had managed to come. In that context, it was my view that production-ready concurrent collection remained an open research problem, while regions are no longer an open research problem. I did not intend to propose regions as a complete replacement for pauseless GC. I was merely trying to say that regions solve *some* of the hard problems that we need to solve, that we need them anyway, and that we should pursue the things we know how to do while we continue to pursue open research problems. I agree with your point that we don't have a solution for all programs until pauseless GC is available. That said, we are unlikely to get to a complete solution in one jump, and we shouldn't neglect the steps that will help us get further along. My belief, by the way, is that pause times mostly are not the issue in the eyes of the world. The much bigger issue, in my view, is data copy delays. It is exceptionally hard to design any sort of efficient I/O subsystem within the limitations of current safe type systems. The advantage to C doesn't lie in manual memory management. It lies in type-unsafety, and the fact that type-unsafe idioms are very effective when you are building idioms for copy avoidance. As a canonical example, look at the BIO mechanism of OpenSSL. One of the interesting properties about the *low* level type system that I envision for BitC is that it can preserve type safety for these or equivalent idioms. I agree with you that a 20ms pause time is a bad thing. It isn't the only bad thing, and it may not even be the most important bad thing. We need to look at the problem space as a complete system. The only type-safe heap reclamation schemes im aware of which are capable > of representing all programs are (a) some variation of mark-sweep-compact > tracing gc, and (b) ref-counting, with some variation of mark-sweep cycle > finding. Therefore, one of these two schemes is a good candidate for the > base of a typesafe runtime (once it meets our no-pause/low-jitter > requirement) to replace c/shlibs/malloc, wheras regions et. al. are only > suitable as optimizations within such a system. > With the release of C4, I think your list may need to be extended. But also, I think you underweight the possibility of (a) being able to choose when to take the GC hit, and (b) being able to control which operations allocate. Point [b] is crucial. In most safe languages there is no contract between me and the compiler regarding what actions may result in heap allocations. > What is your argument? > > Do you believe regions and such are capable of representing all heap > reclamation needs and we simply don't know how? It seems to me any other > argument devolves into gc or manual management, which simply proves my > point. > I definitely don't believe that. What I believe is that when a cave man plans a trip to Alpha Centauri, he's unlikely to make it as far as the moon. Starting with a trip to Mars may be a better plan. Jonathan
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
