Java - made for Real time?

Java is a great language. Made to run anywhere, it started running everywhere, captured a million developer hearts and then bloomed to perfection. Well, almost ... It has the largest developer base now, is a part almost of all open source initiatives, has grown leaps and bounds above any Microsoftian language/platform, but still lacks in ----

One of the strongest points and the weakest chinks about Java has been it's automatic Garbage Collection. It is really very convenient to have a self-contained application (in terms of memory usage and security) and get over the rigmarole of code-based memory management, but everything that comes easy has a cost attached to it. Java's cost is it's unpredictability at times... times when GC takes over and strangles your app, sometimes to an extent of choking it to death (mean OutOfMemory exceptions :)). My move to CTO brought me closer to applications, mainly applications with problems and one such association brought me to an application that just died every 10 hours. Closer analysis revealed that GC's were very frequent and almost all of them were full GC's. We are tuning the GC parameters to make the app perform optimally, but some other thoughts started sprouting in my head...

What if there was a way we could take control over GC and schedule it around better times...most GC's always happened during peak hours...many app's can take this delay (well, if it is in the order of <5 sec), but some mission critical systems just cannot..say for example missile launching systems/ time critical financial systems where every second is just too precious...with bigger heaps, GC takes longer -- maybe in the order of minutes at times and this might be unbearable to quite a few "lenient" systems too..after all, all our applications are driven by SLA's from our customers that specifically measure delivery times and accuracy. Can we afford to let our JVM's run scot free when we are SLA bound? A time-based GC strategy I thought made some sense when such mission critical systems were in question..why not run GC like our nightly batch processes when customers are hardly online? This would mean that during peak hours, our JVM works uninterrupted and during the nights, it just unloads...well, made some sense to me (not a lot :)) as this would make Java behave more "predictably"..but on the flip side is the enormous memory chunk that one would have to allocate to keep our JVM whirring...doesn't make practical sense and maybe that's why SUN didn't have anything like that to offer....my thoughts I thought were in the right direction though and I talked to my colleague Ryan about this and he pointed me to a silver bullet :)

Running a JVM with "deterministic latency"...namely setting some stiff targets to a JVM and make it operate within it..SUN had been worrying about this problem from day 1...JSR 001 was all about this, but the implementation really did take quite a bit of time..SUN came up with the RTSJ spec this May (Real Time Specification for Java) that addresses this concern.

You can find the spec here RealTime Spec for Java

This is a good article for the same...O'Reilly RTSJ

Real-time Java offers a much more reliable and predictable scheduling mechanism, memory handling methods, different memory models, a more predictable threading and synchronization model, asynchronous event handling, and high-resolution time handling. It makes predictable execution the first priority in all trade-off decisions, sometimes at the expense of typical general-purpose computing performance measures. It achieves predictability by having RealTimeThreads that have higher priority over GC threads, by direct memory access i.e by allocating objects on memory that isn't in the heap (so that the app remains unaffected even during collections) and many more features...Read the spec and the article to learn more !!!
Did Java fix the last chink in it's armour? Well, there is still the Swing bloat problem :)....Developers are never a satisfied bunch!!