On Tue, Jul 30, 2013 at 4:07 PM, Raoul Duke <[email protected]> wrote:
> > and I think other criteria are far more important. I'm completely > comfortable with not supporting microsecond trading applications, and I'm > reasonably confident, given some conversations with Tim Sweeney, that the > game examples you cite can be solved. > > woah, can i hire you and him? (i know who both of you are, so i know i > can't, so i'm just kidding of course.) still, these are the domains > *i* care about! games! gc for the cilent side, i'd like that. > You're welcome to try. :-) > one small thing i'd like to interject: personally i think i *get* both > sides of this debate: i *want* gc, but i also *hate* the gc's i've > experienced in clients to date. there's research that in theory could > reduce the suck, but i dunno if/when that will ever get into the > mainstream. > Yup. And it seems as if Azul back-peddled on their open-source release of the C4 collector. Which is just an incredible bummer. While it required Linux kernel mods that were not going to happen in the production kernel, it still serves as nice documentation of techniques. Speaking of which, looking at the talk slides reminded me why those kernel mods were important. TLB shoot-down (e.g. for page mapping updates) on shared memory regions requires IPI operations. IPI's are *incredibly* expensive. At the very least you want to batch the shoot-downs and do a single IPI for a bunch of them. > so i do think the theory is nice, but the practical realities to date > have torpedoed the theory. is it just that developers don't know how > to be careful with gc? > I think it's worse than that. When advocates talk about GC, they tend to forget that GC has some very irritating problems. The big one that comes to mind is that debugging false retention is the next best thing to impossible. The question is "Why is this here object that damned well ought to be dead still around? What's making it stay?" The answer too often amounts to "uhhhhh." False retention caused by excessive liveness can mostly be dealt with by the compiler, though a few cases are hard. Non-nullable pointer types can make this more difficult, because the type system for such pointers stops the programmer from dropping them explicitly. But the bigger issue by far might be described as "unintended retention", where the programmer has inadvertently kept a live root to some big graph. And given that this mistake is hard to find and debug, there's definitely a "scratch my head and curse all the gods" sort of response when it happens. Region annotations may help a bit, because they help document which things are co-live. > like, gc sucks especially hard when the memory gets too tight. there's > got to be some factor 2x, 4x, whateverX more free memz to keep the gc > from thrashing, it would seem... Yes. And that one's pernicious, because it's a run-time issue that can't really be tested during development. Because you need *real* RAM, not virtual RAM, and there's really no way to know in advance how the *rest* of the user's workload on that machine will interfere. And to make it worse you have have a dozen distinct GC runtimes going (python, C#, Java, you name it) all at the same time, none of which coordinate their efforts. And when two or more applications demand a new new-space at the same time, that alone thrashes the machine. So the "mystery factor" is a pretty big impediment, and it's greatly exacerbated by lack of coordination. One of the under-appreciated beauties of the C4 collector is that it's very nearly page-at-a-time. There's really no point where the collector pokes it's head up and spontaneously demands a big pile of RAM. The mere fact that RAM demand is steady-state is an enormous win. Some of the really horrible pause times that David talks about actually aren't the collector's fault at all. *Some* of them are actually caused by OS-level contention between two independent copies of the collector that happen to perform GC during overlapping times when real memory is tight. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
