On Tue, May 15, 2012 at 2:51 PM, Raoul Duke <[email protected]> wrote:
> On Tue, May 15, 2012 at 2:22 PM, Jonathan S. Shapiro <[email protected]> > wrote: > > Concerning manual controls over GC: I understand why you want manual > control > > over GC. Unfortunately, the price is something you won't be willing to > pay. > > overall i don't really want manual control, but the "magically > optimizing compiler" that frees me from that requirement doesn't seem > to exist yet. And it never will. It's not really possible to optimize a dynamic deep queueing problem using static compile-time analysis. > > The price of manual GC control is the requirement that the application > > tolerate out of memory exceptions as a routine case inside critical > > algorithms. > > i don't have that proof in my head, but can take your word for it. :) > but i wonder if that statement is assuming a certain meaning for > "manual gc". > It was. What people usually turn out to mean by "manually controlled GC" is that they want the ability to temporarily turn GC off. > > 1. Implement it by performing a full GC of new-space (in which case you > > should just call that) > > right, i wish we had that in our systems today (java, ecmascripts, > bohem, et. al.?), it seems like they go out of their way to be totally > uninfluenced by the programmer. i can respect certain arguments for > why that is just so, but it is sad when trying to hack performance > improvements into a game or embedded system. > Boehm has an especially hard problem on this, because it is a conservative collector. In Java, I believe you can invoke gc.gc(), but I'm not sure if there is a way to state that you only want a generational collection to be performed. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
