The problems of concurrent garbage collection in games are not imaginary, as you seem to be implying. Keep in mind that 60 FPS allows a maximum of 16 ms of GC per frame, and that's assuming the game has no work to do at all. Turn on the GC profiling sometime in your browser of choice and look at the numbers sometime; then extrapolate that to the slower CPUs and RAM on mobile and you can see why this can be a cause for concern.
This follows his ongoing Haskell experiments and with a short deviation to Scheme/Lisp.
I was just trying to make the point that known game developers do value GC languages for game development, even if nowadays that is still not mainstream.
I am old enough to remember the days C was considered too slow and together with Pascal was just used for prototyping ideas, if ever. Times change.
For a console, it's actually an easier task, because you are not as worried about CPU usage (in the sense that if you use too much CPU, you kill the battery)
Metronome, and other garbage collectors, can do consistent bounded near-real or real time time collection with bounded CPU usage.
They can hit 6ms without too much trouble.
It seems to me that the goals of browser GC's are essentially the same as those of Dalvik: allow Web pages or phone apps to hit 60 FPS. To this end both SpiderMonkey and V8 have incremental GC's. (They actually have an easier time of things because they don't have to deal with multiple threads sharing a single heap.)
SM shoots for 7 ms for incremental time slices, as I recall, but in practice the major collections can lead to pauses longer than that. Incremental isn't a panacea in practice; in high allocation or high-CPU-load scenarios you either get pauses if you're soft-real-time or you starve the mutator for resources (which can drop the frame rate of the game) if you're hard-real-time. Ironically, decreasing the time slice can sometimes make the pauses worse, because when you're in an IGC slice more stuff is barriered.
> Metronome, and other garbage collectors, can do consistent bounded near-real or real time time collection with bounded CPU usage.
Dalvik doesn't use Metronome (or Azul C4, ...). It uses a concurrent GC for minor collections but sometimes has to stop the world for major collections, last I looked (granted, my knowledge is ICS only, so perhaps there have been improvements since then).
(Note that I'm not trying to argue that GC's are bad, or that Dalvik's GC is bad, or that a sufficiently good GC wouldn't be good enough for most games; those are questions that would generate more heat than light to debate. I'm simply pointing out that game developers' concerns about Dalvik's GC are not unfounded or imaginary.)
The point I am trying to make, is that in the real world using Java is like using an automatic: it allows you to focus on the big picture while it optimizing the little bits for you the best it can.
It's just unnecessary. You can write "safe" C and C++, you just have to know what you are doing to begin with. Also, don't forget about the massive amount of native frameworks that have been developed already. Why rewrite an engine which already exists just so you can use Java?
Java has its faults, but it's a higher level language than C++, and that lets people write code in it more quickly.
Memory management is a huge problem pushing performance. You can still write efficient Java by doing things like no newing of object in ticks and stack arrays but gamedev is heavy in management of memory access/organization, stack vs heap allocation and other things that take lots of work or are too hard to control in Java or other GC platforms (C#). Though there were a ton more XNA games (C#) than Java even today but that has since been discontinued. Windows Phone 7 also limited its potential due to no native access and requiring XNA only games. Android didn't really take off in games until the NDK in Android 2.3 which was deemed a game developers OS. iOS had it right since the first SDK allowing C/C++ and Objective-C or Objective-C++ which allows mixed that I have seen in all custom engines for iPhone.
It seems like hard-core gamers and game developers forget that pretty frequently.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.66....
Games could be written in Java. Just intelligently schedule garbage collection and in return you get to use a very fast safe, well-optimized JITed virtual machine.
They won't be, of course, they'll be written in NDK because the culture of the game industry is a powerful one, and one that takes pride in their ways. It would be like telling a race car enthusiast that continually-variable transmission is better for racing because even though it's less efficiant it allows the driver to focus on driving and is always in the exact gear needed. The driver would never except this because in their mind they are an amazing driver and manual makes them faster because it is more efficient and makes them feel cool.