On Mon, Jul 15, 2013 at 8:48 PM, Jonathan S. Shapiro <[email protected]>wrote:
> My guess is that the C4 collector will outperform malloc/free in your > example, with *no* performance degradation in the mutator. > I 100% agree, for workloads with spare CPU. CPU bound workloads, no. > 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. 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. The onus is not on C/C++ users to prove it can be done. The onus is on us (proponents of GC). So far GC has done well taking over less latency centric tasks with constrained heaps. No so well on large heaps or latency centric software. I'm confident Azul-like kernel changes will *eventually* make it into kernels. I guess I just think our pressure is better applied here, where it increases GC's ability to achieve our goals, than on advocating the end of software systems which pausing-collectors have no hope of rivaling. @Bennie - The C4 kernel changes are not about allocations, but bulk MMU page protection changes. They use MMU page-protection for a hardware assisted concurrent write-barrier, and to do this they have to change tons of MMU page protection bits. The standard kernel interfaces don't make this efficient enough. (or at least that is my understanding/memory of it, the paper tells the real details)
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
