> > > 1) The collector often needs to visit cold memory pages, even ones > that may be swapped to disk. It's indeed horrible to bring a page from > RAM all way up to L1 cache, or even worse from disk to RAM, just to > perform a marking cycle that may even not find anything to deallocate > in that page. This is one are that receives intense research; there > are already techniques that make the problem much smaller, but it's > not yet in the solved problems category.
this is a horrible problem!!!! But I wouldn't say that this is a problem with GC but more with how kernels have evolved to manage memory. In this regard the JVM is *unlike* any other application. That said, there are some hardware/OS optimizations that could be applied to make the problem more palatable. First from the hardware, about 1/2 of the read channel is consumed doing thins that could/should easily be done with a simple instruction in the CPU. Example, zeroing out incoming cache lines. About 1/3 of the write channel is consumed simply writing dead objects. Simple change and we'd see some big wins but mostly only for VMs. From an OS POV, Azul has modified the Linux kernel jacking up the page rates to the point that they can simulate fast-barriers on some Intel processors. This is a feature they designed into their Vega chips. This features allows them to continuously GC without pausing application threads under the vast majority of conditions. On the Vega I was able to run a bench that produced 45Gigs of garbage / second before the app wasn't able to make useful forward progress (GC threads took over all the CPUs all the time). Most applications run into other issues that throttle object creation rates to less than 1 gig / second. Another kernel optimization to consider is large pages. > > > So this issue boils down to: are Java (and other GC-happy-languages') > programmers less willing to use these optimizations, because theirs > memory management skills are dumbed down by the convenience of GC? I > think this may be true for the typical run-of-the-mill Java app > programmer, but also very likely true for the typical Joe-sixpack C/C+ > + app programmer (are there any today? well there certainly were, > before Java became popular). Linus may have a very high regard for > the skills of C programmers, but he's biased by his overwhelming > collaboration with kernel and compiler hackers - not a "typical > programmers" community in any language. GC is the driving force behind huge gains in developer productivity. There are things that simply wouldn't have gotten done had we'd only C++ to use. VisualBasic was very very popular because it allowed ordinary people to do useful things. Knowledge of memory management is highly over-rated skill. Regards, Kirk -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
