On Sat, Jul 13, 2013 at 9:56 PM, David Jeske <[email protected]> wrote:
> Couple thoughts.. > > 1) btw, if you have not seen it, this recent tome of a blog post has an > interesting view of the performance-vs-gc fight.. > > http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ > It's an interesting blog post, and it's critique of GC is largely obsolete. GC has been around for a long time. Work on GC is characterized by long periods of small incremental progress and then an occasional big jump. Copying collectors and generational collectors were jumps. Concurrent collectors are another such jump. Everything in that blog post is true for pre-concurrent collectors. Much of it is obsoleted by concurrent collectors. Things like ARC, where they work, are good to have. And the argument that small devices face memory pressure is valid *for the moment*. But the trend in small devices has been toward increased memory size, As much as I admire the care with which Crawford has put his post together, he's wrong about package-on-package. Most notably, chip stacking has become a reality, which *reduces* power requirements for memory. It's no longer necessary to implement RAM in a process chemistry that is more appropriate to CPUs. Over time, that will prove game changing. All well and good, but the argument about memory availability could still be relevant for deeply embedded devices. My personal bias there is that successful software for deeply embedded devices shouldn't be allocating memory after initialization. In that case, of course, you simply turn the GC off, and it doesn't matter how slow it is or isn't. The interesting discrepancy I note from Crawford's post is the juxtaposition of "CPU doesn't matter" with "GC is slow". This is, of course, the situation we want from the perspective of concurrent collection - it means we can use idle CPU cycles to reduce the physical memory requirement. The most interesting point about the Azul collector for the present discussion isn't that it scales to 300GB heaps (actually more). The most interesting point is that the concurrent collector keeps up with the mutator. The real question, I think, is whether the Azul C4 techniques can be implemented on weakly consistent memory architectures like ARM. I simply don't know the answer to that. The problem with ARC, by the way, is that some data structures inherently require cycles, and some usage patterns are not amenable to resolution with weak pointers. The AST tree in the current BitC compiler is one example of such a data structure.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
