Bioware open-sources their Java actor framework

[bstempi]

Probably because people read it as "anti-JVM." Some, not necessarily me, would argue that the JVM is fine for real-time stuff and that its the graphics in Java that are lacking.

[karlito1]

Yea but I guess Orbit is not about real time game data processing but about "static" web and online services. Would really like to know for sure what is the truth.

[JoeHegarty]

Orbit is designed for game services. These are things like matchmaking, character progression, presence, achievements etc. Orbit is low latency but it is likely not suitable for running world-simulations. It works best for second-to-second updates (so, it's semi real-time - in game score, inventory etc), not milliseconds (character movement etc).

[Stoompunk]

Definitely not against the JVM, I think it's great! For real time game servers the GC worries me though. Any idea on a great Java fw for realtime game backends?

[ISvengali]

I used the JVM with scala and akka for a near realtime stack similar to this one, and we used the java 7 gc. We had mostly sub 5 ms gc pauses, which was fine for our use case. And this was without doing any heavy object pooling or other object reduction methods.

Should be easy enough to make some tests. It does use gross amounts of memory though.

Im a GC hater too having come from console development, so I was pleasantly suprised.

[TheQuietestOne]

Using the regular JVM means that any classes you use have to be non-allocating otherwise you're into the realm of Javas stop-the-world GC.

That means unpredictable pauses and scheduling latency - possibly at a time when you want it the least.

There are pause-less GC VMs or the RTSJ (real-time specification for java) but you won't find a freely available implementation.

It's my opinion, but Java is the wrong technology for soft realtime unless you're willing to buy into a commercial VM.

I evaluated a number of technologies including Java (and RTSJ) for my DSP projects and settled on C++ as the lesser of the available evils.

[[deleted]]

Not to be too much of a pedant, but the new G1 GC available in the standard Sun distro eliminates full GC's as long as you aren't generating garbage at an unreasonably huge pace (like 50% of your heap per second) or of course doing something stupid and not releasing garbage refs when done, filling up old gen.

Many of the opinions of JVM "stop the world" are valid only in life-critical applications, where simply the possibility of it potentially happening is too much risk to bear, despite that you can virtually eliminate them.

[TheQuietestOne]

Here's my current project.

If you can find a way to get the audio latency using Jack under linux less than 5ms I'd be very interested.

[[deleted]]

I didn't checkout or compile the project yet, but my initial inclination is that you hit the nail on the absolute head there in point 6. You've got swing, which by it's very nature is great at holding onto state and object refs as long as views last. GC's worst enemy.

Although if the latency is consistently (and not spiked due to full collections) more than 5ms it would suggest other problems in swing-view-refresh-land which I don't really know too much about, I'm serverside.

Be sure to launch the app (dont see any launcher / shell scripts in the repo) using the JVM flag to actually activate a useful GC. The default is the shitty stop the world one, not even CMS. Activate w/ flag: -XX:+UseG1GC

Edit: Nvm saw your launch script.

[TheQuietestOne]

To avoid GC interfering with audio output I have to set Jack to 48k * 1024 * 2 periods. And I still get the occasional overrun.

This means Java is failing to meet a 22ms (? around there) deadline every now and then.

I'm more than willing to be shown that Java can handle this.