I don't think this is true. It's considerably more than rendering--it's reactivity. You need to handle audio streaming without pause, be able to process and dispatch input events seamlessly as well (I don't even know how you'd do this), so on and so forth. You'll essentially need to pull everything except actor logic out of the Java layer. Even some of that will be latency-constrained.

If anything, I think Unity is on the right path here: embed a sufficiently optimized virtual machine inside an engine that does all the hard work. But Unity still suffers from serious perf issues with nontrivial scenes. Like I said in another reply to you, object pooling is still heavily used in Unity because of the costs of object creation and destruction.

> On relatively small heap sizes (under a GB) GC on recent PC hardware usually fits into the equivalent of a single frame -- under 30 milliseconds. Concurrent collectors would rarely need anything more than that, and wouldn't stop the world in any case.

Sure, but that's too slow. The human eye can easily, easily, detect a dropped frame. Concurrent collectors (you mean Azul and friends?) are a possibility but we'd need a portable one that's freely licensed. If you've got one in your back pocket...gimme. =)

> The question here is, can you build a stable high performance rendering system on the JVM? If not, what would you have to change to be able to do that?

This is a tricky question. My instant reaction--"you can't"--feels right for the current state of the JVM. I do think something like Azul or another fully concurrent collector helps. But even then the JVM just has its limitations. Like, you're going to blow up your cache iterating a list of whatever your "GLbuffer" analogues are, unless you decompose all your objects. In most games way more of your code ends up being engine code than game logic code and so you're kind of hosing the main reason to use the JVM: a mostly-clean object-based system.

At that point, I'd just write C++ and embed a scripting language. (Recurring theme!)

> And JMonkeyEngine shows you can do a lot with what's there right now.

JMonkeyEngine is actually a major reason why I'm not using the JVM--if they can't get it good enough, I sure won't, right? IMO, you don't get enough from using the JVM (unless that's all you know, which'd just be sort of a shame) to make up for its limited platform reach and its perf issues. What you can do with it, right now, relative to just sucking it up and writing some C++ (and I do mean "sucking it up", I hate writing C++), just isn't enough.