On Mon, Jul 15, 2013 at 10:21 PM, David Jeske <[email protected]> wrote:
> On Mon, Jul 15, 2013 at 8:48 PM, Jonathan S. Shapiro <[email protected]>wrote: > >> > Setting that aside, kicking straw dogs is not a good use of time. Unless >> there are meaningful programs that actually exhibit this behavior, it's an >> exercise in intellectual masturbation. One can, of course, create >> pathological cases for *any* allocator, including fully manual storage >> management. >> > > There are tons of meaningful programs that exhibit this behavior. They are > currently written in C/C++. I think computer-games make a good case study, > specifically because they *are* using GC (often Lua, sometimes Mono), they > just can't use it for the majority of data -- which is kept in C++. One > also doesn't have to throw a stone very far to find a JVM webserver which > has had to go on a heap-diet. > I do not believe you. Or at least, I think your analysis is flawed. Examination of such "large" programs tends to reveal that the overwhelming majority of long-lived data consists of value types. That is: unboxed types that contain no references. Such data structures do not need to be traced, rarely need to be relocated, and are treated specially by any decently intelligent runtime in any case. It's the "reference containing" subset of the heap that gets traced. That's not to dispute your point; just to clarify the actual technical issue. The app scenario that is problematic is applications that involve large numbers of long-lived objects that (a) contain references and (b) those references are mutated with a rate of change above some hard-to-specify threshold [potentially creating garbage]. Actually, it's not the rate of mutation per se. It's the rate at which mutations cause objects to become orphaned, which is kind of hard to understand. There are basically three things we can do about this. 1. Exploit static analysis, where possible, to gang related objects together. For example, the notion of an owned object can be extended to a notion of a single-entry object subgraph. Such a subgraph constitutes a closed sub-heap, and can be collected independent of the larger heap. I'm very fond of the introduction of explicitly named and region-bound heaps to support this type of construct. 2. Adopt region-based collection intuitions. More precisely to support region-bounded collection, because it turns out that regions tend to produce a whole lot of garbage within region X before region X ceases to be live. But what it *does* do is establish a scope of collection that is much smaller than an entire heap. Also, the code patterns that create in-region garbage can be conservatively identified by the compiler. 3. Shift to hybrid management strategies, whether those are counted or owned or linear or what have you. There is unfortunate anecdotal experience with linear types that suggests that merely mortal programmers cannot deal with them - or at least, not in current programming languages. Part of the problem is that the languages in question didn't have a notion of non-escaping pointer captures (borrowed objects). Part of the problem is that mutating idioms and linear pointers don't get along very well. Part of the problem is that we're just still exploring the space. But in all of these cases, Having a compiler provide alias type inference would be really helpful. > With respect and humor, kicking straw dogs seems a saner approach than > legistlation to ban use of tools that meet there needs without proof the > alternatives are sufficient. > Part of the purpose of taxes and regulation is to raise the cost of socially destructive behavior until its transfer costs are accounted for. Ideally, forcing the prices to match the real societal costs leads to invention of better solutions. At minimum, it forces people to look real hard for better solutions and minimize use of bad ones. Technologists, understandably, look for solutions in purely technical terms. The societal cost of unsafe languages is far past the threshold where regulatory approaches are warranted. Jonathan
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
