On Sat, Jul 13, 2013 at 1:22 PM, David Jeske <[email protected]> wrote:
> On a related note, some things you said long ago about GC and bitc have > been swirling around in my head, and I recently have been trending towards > a different conclusion than I had previously. I'm still a big proponent of > adopting true pauseless GC solutions (like Azul-Zing), however, I think we > have under-exploited possibilities to *dramatically* reduce pressure on the > GC heap. Both by favoring "allocation-less" standard libraries, and by > creating a more comfortable pattern for C-esq > refcounted-struct-array-elements, > with typesafe-handles (instead of pointers) between them. Between these two > strategies, actual GC-traced pointers might be kept to a reasonable level > while still achieving typesafety. I hope that very terse description makes > some sense. > > I'm not going to say any more now because I don't want to derail the > intent of your thread. Happy to discuss more on-or-off list. > So the first thing to say is: I agree, and this is one of the reasons that BitC re-introduced pass-by-reference, which is something that seems pretty important once unboxed structures go back into the language. I think the question of library allocation is subtle. Allocation *per se* isn't the problem. The problem is GC pressure, and short-lived objects generate qualitatively different pressures than long-lived objects. My sense is that there are four different kinds of allocation that are performed in a library code: 1. Allocations that are reachable from the return value [young] 2. Allocations for computational storage internal to the call [transient] 3. Allocations that become reachable as a result of modification of some argument, e.g. appending to a passed-in collection of some form [hard to say] 4. Allocations that become reachable from the internal global state of the library. [potentially long lived] Of these, my sense is that temporary internal storage is the most amenable to pressure reduction. It's exactly the kind of thing that can be moved to a region-based heap with GC as a fallback. I can't claim to be up to speed on recent work related to reference counts, but the best work I know about (a) requires sophisticated and error-prone analysis in the optimizer, (b) doesn't tend to be concurrency friendly, and (c) especially so on machines with weakly consistent memory models. On balance, my feeling is that I'd rather put my energy into regions, which is something I want anyway, and into GC performance. Reference counting is something you should feel free to do in *your* fork of the optimizer. :-) Something similar to linear types might be useful too. This is all a big topic. I think it's something that can't be done without some iteration. Jonathan
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
