On Fri, Jul 26, 2013 at 1:43 PM, David Jeske <[email protected]> wrote:
> On Fri, Jul 26, 2013 at 12:07 PM, Jonathan S. Shapiro <[email protected]>wrote: > >> > If inference can use the right pointer type enough of the time, and we >> only have to hand-annotate a smaller subset, I think that could make a big >> difference. > > > I don't see how this affects practical issues. If library authors are free > to perform GC dependent operations, then they will, and a non-GC user will > not only have to avoid their libraries, but he will have to avoid all > libraries that use those libraries. > BitC is a managed language. Period. Full stop. It is not, and never has been an objective to support any general-purpose non-GC mode of operation. There has been discussion of implementing an effect type indicating that no heap-based allocation has occurred. If this holds for the program main entry point, then GC can safely be turned off. There has been discussion of a first-class region system. Experience and simple examples demonstrate that a region system does not eliminate the need for GC. In the past few weeks there has been discussion of ARC. This also does not eliminate the need for GC. You appear to be talking about a different thing entirely, in which allocation and release are fully manual. Since manual storage management is not a goal for BitC, the problem of library modes isn't of any interest to me. In making the decision to abandon GC, Rust is making a fundamental mistake. I'm fine with the suggestion that we adopt ARC and/or regions, but due to the presence of cycles and the presence of regions whose size cannot be statically bounded, these do not remove the need for GC. > Of course we could explicitly create a set of "GC okay" and "no GC" > libraries for a single language. I'm arguing that we have effectively done > that by making "GC okay" and "no GC" languages -- and with good reason. The > construction effort put into libraries written in a language so far > outweigh the effort of the compiler and runtime that it simply doesn't > matter if you re-use the language across those two cases. > Horse hockey. The only reason we have manual-storage libraries is that they were written for C and C++. Nobody has made any claim that the absence of managed storage in these libraries is a good thing. > There has been good work on region inference. An interesting pair of >> questions is: >> >> 1. Under what conditions should we GC a region? >> 2. How often can a compiler determine [statically] that these >> conditions are not met, >> and GC is therefore unnecessary on that region. >> > > My interpretation of this is that you're trying to apply > automatic-compiler-magic to allow code to be used in GC or non-GC modes. > Hopefully my comment above makes it clear that this is not true. What I *am* hoping to do is to use compiler magic to reduce the utilization of the GC heap so that GC pressure and/or total RAM requirements are suitably reduced. I understand what you think you are after. I don't think that runtime design is viable for high-confidence systems. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
