JTRES 07
Last week we held the 5th annual Java Technologies for Real-Time and Embedded Systems Workshop in Vienna, Austria at the Technical University of Vienna. This is the place to be if your working on or with the RTSJ and other ideas and designs around using the Java Platform or Language for applications needing temporally predictable execution behavior.
I served as program committee chair this year. The proceedings are published in the ACM Digital Library as they were last year.
We had 34 papers submitted and accepted 25 for presentation and publication. In the program were also, one keynote by Laurie Tolson and John Pampuch (executives at Sun Microsystems), 4 invited talks, two panels, and one BoF. Needless to say the attendees were busy for two and a half very full days.
Martin Schoeberl did an outstanding job as General/Local chair. All the necessary things happened as they should and the social events were memorable. Thursday night every one went for a ride on a really big Ferris Wheel (like the London Eye but older and a bit smaller) the dinner at a great, truly Austrian restaurant. The menu included a whole, barbecued pig....
During the BoF I proposed two initiatives which were enthusiastically accepted by the community.
First, starting with the great work and presentation of Brian Doherty in which he told us about how he modified the SPEC jbb benchmark to more accurately show true response times of the transactions. Sun will be proposing to SPEC that this work form the basis of a new SPEC benchmark specifically designed to measure the predictability of RTSJ implementations. I feel our community is in dire need of such a formal, accepted, accurate benchmark if we are to serve our customers well. I, Sun, invited everyone to participate with us at SPEC in the creation of the benchmark.
Second, It's been clear to me for a while that the RTSJ might be more aggressively implemented and marketed if there were a way to leave out some of the more exacting features, specifically the no-heap execution mode (NHRT's, ImmortalMemory, ScopedMemory, etc.). This mode allows temporal precision (in the tens of microseconds in typical implementations) which is really overkill for many, many real-time applications. So, the proposal was to initiate a new JSR, co-led by Sun and IBM to define the partition. The Original RTSJ (as defined in JSRs-1/282) will be called, Tor and the new piece, which will be a strict subset of Tor, we called, Sue, (for, a Subset that Useful but Easy to implement). We expect this to be a rather quick effort. Once done, we'll have Peter Dibble and TimeSys create the necessary partitioning in the RI and TCK. I expect that more and new implementations of real-time Java will embrace Sue and move forward quickly on compliance with Peter's new TCK. Of course, at Sun, we'll continue with our Tor implementation.
Posted at 12:24PM Oct 05, 2007 by gregbollella in Sun | Comments[0]
Initial entry
My life's work is real-time everything. From scheduling, to languages, to systems, to education, to specifications, to benchmarks, to standards, to the Real-Time Specification for Java (RTSJ). I've spent the last 15 years thinking pretty deeply about the intersection between general-purpose languages, systems, applications, and market and the real-time counterparts. And, believe it or not, the intersection is not the empty set. Trends in the general-purpose world are generating requirements that can only be met by real-time systems.
I have a lot to say and I'll seemingly be all over the place for awhile until it all comes together, sometime in the not too distant (and not too many entries) future. I'll talk about real-time in general, real-time scheduling, and a lot about the RTSJ and Sun's implementation of the RTSJ, the Sun Java Real-Time System 2.0 (JRTS). It will also be interesting to discuss real-time garbage collection, something currently all the rage in the enterprise systems world. I'll also define terms, debunk myths, and, hopefully, generate lots of controversy.
When customers ask if they need a real-time system I reply, "If all you, or your application, think about is how many transactions-per-second, then no, real-time probably isn't for you. However, if you have a requirement to execute a particular transaction at a particular millisecond (a millisecond that cannot be known until it happens) then, yes, real-time, and especially JRTS, is for you."
Yes, indeed, general-purpose system architects are now concerned about sub-millisecond response time at any, unknown, future, arbitrary millisecond.
The first step to the road to real-time enlightenment:
Real-Time != Real-Fast.
Let's say that again, all together now,
Real-Time != Real-Fast.
Real-Fast is good, yes, but having a fast system does not guarantee that you can depend on executing that particular transaction at that arbitrary millisecond somewhere in the unknown future. Only real-time systems can do that for you.
I'll end this first entry with an example of how customers respond to the RT != RF issue. Typically, real-time systems have lower throughput than non-RT systems and this engineering trade-off is well known and accepted in the RT community. (I'll cover the issue in depth in later entries). I, when presenting JRTS to customers always include the caveat, JRTS does sacrifice throughput to get predictability. When I mentioned this caveat to the CTO of a major financial firm considering using JRTS for an automated trading system he replied, "What? What do I care? If I have predictability I get throughput by simply adding machines!" This comment is great and absolutely right-on-target. I'd only add that the inverse is NOT true, you cannot get predictability by adding machines. Greg
Posted at 10:16AM May 30, 2007 by gregbollella in Sun | Comments[3]