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. i'm not saying that means everybody should stop looking for it. i just mean that i wonder if there are other ways of looking at the "manual control" that is not more harm than help. in other words: the game folks already do all sorts of tricks so could those things be incorporated into the overall memory / GC system so that everybody could use them if need be, when it comes time to noodle around with performance? yes they are diluting the benefit of really automatic GC but maybe we gotta do that for now. if we can figure out what the spectrum of options are, and grade them from "most evil and most manual - but no hiccups" all the way over to "most automatic and blissful - but juddery", then we can give folks the tools to try to go down the slippery slope with some control over the toboggan. > 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". > For this and several other reasons, I would argue that what you > should really be seeking is the ability to write allocation-free critical > code. i think there is probably a wide gamut of use cases. there's stuff like a game that isn't "critical" in the life-saving sense, but nevertheless i want it to maintain 60fps. there's stuff like the heart pump that really is "critical". and there's stuff like systems work that isn't always death if it fails, but it really shouldn't fail, so it falls sorta between the game thing and the heart pump thing. the only point being that for lesser definitions of the term "critical" we might have more options than having the magic (nice) ability (talent) to write allocation-free critical code. i apologize if i sound like i'm not paying attention to *your* use cases when i mumble about oh can we just do something "good enough" for e.g. *my* games? :) > Today's hack is tomorrow's backwards compatibility nightmare. The lower you > go in the software stack, the bigger the impact of a compatibility nightmare > is. Language design sits very low in the functional stack. Tread carefully. i don't doubt, and am certainly neither smart enough nor experienced enough to claim otherwise; i'm paranoid / a fan of murphy's law so i would tend to believe. > 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. > 2. Implement it by region analysis, discarding the function-local region. In > practice this may not turn out to release any storage [see below]. > 3. Implement it by escape analysis and aggressive stack allocation. This > approach works, but it has a cost [see below]. those are the kinds of things that, just based on the natural language vocabulary used there, i figure wouldn't show up in the GCs i get to use for a long time. i figure evil but shippable manual controls / hints to the GCs would more likely show up. like, they don't even have to be in the source language; they could be annotations that spit out metadata xml files that hotspot reads in along side the .class files, so it knows in an AOP fashion when to do the manual GC bidding. > lots of details i certainly hope that intelligent and motivated people succeed in figuring these things out, and making them available to plebes like me. and obviously it requires discussions like those on the BitC list, and other places, to think through the wrinkles up front. now, all of what i'm wondering here might be irrelevant to BitC's higher-brow (in a good way) goals, and would therefore basically be off-topic for the list. sincerely. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
