Real-Time Java for the Real World
All the power and benefits of the Java platform plus unprecedented control
» Download Java Real-Time System Now
Q: 1. What does real-time Java really mean? "Real-time", as used in the context of the Sun Java Real-Time System product, means predictable. Real-time does not, in this context, have the sort of "in the moment" meaning that you hear in, for example, gaming circles. Real-Time Java means a version of Java that can support predictable responses to real-world events as defined by the RTSJ (Real-Time Specification for Java). The RTSJ is the standard definition for real-time behavior (JSR-001) in the Java world. Q: 2. Why isn't Java technology used predominantly in real-time systems today? The adoption of Java technology in real-time domains has been traditionally limited by the inability to predictably control the temporal execution of Java applications due to:
These issues have all been addressed by Java RTS 2.2 (and earlier releases) on the currently supported platforms: Solaris 10 and some real-time Linux implementations. This allows developers to target real-time applications using Java, which means that they also gain all the benefits that Java provides by its inherent design, such as portability and security. Q: 3. What kinds of applications are well-suited for Java RTS? Complex applications comprising significant non-real-time logic, plus either some soft real-time logic or some hard real-time logic, or both. (Note: Non-real-time logic reflects standard Java programming. Soft real-time logic means that responses to real-time events might occasionally fail to occur within the given set period; occasional failures are not considered as critical. Hard real-time logic means that responses to real-time events must never fail to occur within the set period; any failure is considered as critical.) Q: 4. Is Java RTS compatible with Java SE? Yes, and Java RTS 2.2 in particular is an implementation of J2SE 5.0u20, with RTSJ extensions. Q: 5. I have an application that currently runs on Java SE -- will it run under Java RTS? Yes. This is because Java RTS is compatible with the Java SE specification (see previous question). The RTSJ specification only restricts the semantics of the Java Language Specification and Java Virtual Machine (JVM) specification to a subset, it does NOT allow syntactic extensions which could break existing applications. Said another way, all compliant RTSJ implementations must pass the Java SE Technology Compatibility Kit (TCK) in addition to the RTSJ TCK. Q: 6. Does Java RTS require an operating system? If so, which one? Yes. Java RTS 2.2 uses Solaris 10 (Updates 6 and 7), or Linux with real-time POSIX APIs. (For some further details, please see section Java RTS Minimum Recommended System Requirements.) Future releases will use other real-time operating systems (RTOS's) as well. In order to provide real-time capabilities at the Java level, Java RTS requires a real-time capable operating system underneath it to achieve the low latencies typical of practical real-time systems. Note that the RTSJ can only be as good at real-time as the underlying RTOS is, unless that RTOS is modified to provide more advanced real-time functionality. The Java RTS team is not in the OS business and will thus use the full capacities of the underlying OS. That being said, we are in a position to do very clever things with the underlying OS because the RTSJ offers such a simple API. For example, in Java RTS for Solaris 10, the full power of this OS' real-time features is incorporated within the JVM and exposed to the RTSJ application simply as defined. Q: 7. Does Java RTS have to run on a SPARC system? No. Java RTS 2.2 supports both SPARC and x86 platforms (on Solaris 10), thus greatly expanding its reach to widely available, standard platforms. Furthermore, Linux (with real-time POSIX APIs) on x86 platforms is supported as well. (For some further details, please see section Java RTS Minimum Recommended System Requirements.) Java RTS is currently running on systems as diverse as laptops, desktops, large servers, and Sun's multi-core offerings. Future Java RTS releases will be supported on other OS's as well (see next question). Q: 8. Are you planning to support other platforms with Java RTS? Yes. A version for Linux with real-time POSIX APIs is currently supported. (For some further details, please see section Java RTS Minimum Recommended System Requirements.) We are targeting the broadest possible Linux support, but the real-time requirement remains and limits the range of choices. We have no plans to support Windows XP or Vista at this time as real-time behavior is not well expressed in those systems. We are also looking into expanding support for other hardware platforms, such as x64, ARM, and PowerPC, as well as support for other real-time operating systems (RTOSs). We welcome your feedback on any platforms (OS-CPU combinations) that are of particular interest to you. You can let us know either through our feature requests survey or by contacting Java RTS Engineering and Marketing. Q: 9. Does Java RTS use a real-time garbage collector? Yes. Java RTS 2.0 was the first Java RTS product release to include the RTGC -- a real-time garbage collector that includes a further enhanced version of an innovative real-time GC algorithm that was created in concert with Lund University. It provides Java developers very fine-grained control over the behavior of garbage collection (dynamic memory management) in a real-time environment, while ensuring that the integrity of the environment remains preserved. It requires only minor changes to existing code. The RTGC is tunable so that it can provide the optimum performance for every application environment; latencies in the hundreds of microseconds can be obtained. Q: 10. How fast is Java RTS? How do you measure Java RTS's performance? Java RTS performance is measured in two ways: throughput performance for non-real-time logic, and predictability performance -- the maximum latency and jitter that are still acceptable -- for hard real-time logic. (Note: latency is defined as the average time it takes the system to respond to a higher priority interrupt; jitter is a measure of the variability of the latency number.) For non-real-time logic, Java RTS has been seen to perform up to 85% as fast as the equivalent non-real-time system on standard Java benchmarks. For hard real-time logic, Java RTS for our reference platforms has a maximum latency of 20 microseconds and a maximum jitter of 10 microseconds. Q: 11. Can I write a real-time program on Java RTS that will run without change on another hardware platform? In short, yes -- but there are caveats. Real-time Java applications that run on Java RTS for one platform are fully portable to Java RTS for any other platform, since both implement the RTSJ. However, performance characteristics might vary, or low-latency behaviors might not be possible, depending on the platform. For example, if you take a functional real-time program running on a 4-way 2.0 Ghz system and run it on a single processor or perhaps a 2-way system, the program will run, but it will be less likely to meet its real-time deadlines -- simply because it might not be able to get enough work done in the specified period to satisfy the real-time system needs. Some systems, such as in many cases laptops, do not have sufficient hardware support for a high-resolution clock. This might mean that the necessary clock granularity will not be fine enough for the program to succeed. So, in these cases, while the program itself might run, the overall real-time solution might not work properly due to basic hardware issues. Q: 12. Can I take code written for Java RTS and run it on another vendor's implementation of RTSJ? If that vendor's product is fully compliant to the RTSJ, then the program should run. As mentioned above, different hardware and/or system implementations might mean some adjustment to the program is necessary, but it is far simpler than the typical full rewrite of the program as would be required when moving traditional real-time systems from one vendor to another. See question 24 for more details. Q: 13. Does Java RTS work with any partner products? Yes. For example, multiple RT-CORBA ORB vendors have rewritten their ORBs to the RTSJ APIs and are offering commercial versions of their RT-ORBS based on Java RTS. In particular ORBexpress and DDSexpress from Objective Interface Systems, Inc., and OpenFusion RT for Java from PrismTech, support Java RTS. A more recently released middleware product based on Java RTS is RTI Data Distribution Service from Real-Time Innovations. We are also aware of Java RTS-based product development and deployment in areas such as financial services, industrial automation, telecommunications, and defense (radar control, navigation, etc.). Q: 14. Will the RTSJ specification be revised again? Yes. In a nutshell, here is how the RTSJ evolved and where it's heading: The RTSJ is the outcome of JSR-001 (the first Java specification launched through the JCP (Java Community Process). The first version of RTSJ was 1.0, which was upgraded to 1.0.1, 1.0.1b, and then 1.0.2. The next major revision will be RTSJ 1.1 (JSR-282). Java RTS 2.2 (the current Java RTS release) is compatible with RTSJ 1.0.2, whereas RTSJ 1.0.1 is the underlying specification for Java RTS 1.0. Q: 15. Is Sun accelerating investment in real-time Java? Sun has been involved in real-time Java since the beginning and will continue to invest strongly in this area as evidenced by the advanced features and observed performance of our latest Java RTS release (2.2), also available for Linux (on x86) with real-time POSIX APIs. We are also very interested in your suggestions for features and enhancements that you would like to see in future implementations of Java RTS. You can let us know either through our feature requests survey or by contacting Java RTS Engineering and Marketing. Q: 16. How do I purchase Java RTS? How much does it cost? Java RTS has an innovative pricing model that starts at $6500 per socket/CPU for development or internal deployment. This number includes one year of basic support. For commercial external and volume deployments, Java RTS has a value-based pricing model that scales to suit your needs. Your sales representative can go into more detail. Java RTS is available only through Sun's OEM Sales channel, which has knowledgeable sales staff worldwide. Please contact them by sending an e-mail, or by calling a convenient phone number listed on our Contact Sun Sales page; for the U.S.A., this is +1-800-786-0404, Prompt 1 then Prompt 3. For information on Sun's Java RTS product and related optional services, please contact Java RTS Engineering and Marketing. Q: 17. What kind of support does Sun offer for Java RTS? For customers who are in the process of building their Java RTS applications, Sun offers the Development Support. Standard level of Development Support is included in the Java RTS license fee for the first year of the project and can be extend beyond one year for a fee or upgraded to the Premium level. For customers who are deploying their Java RTS applications in the production environment Sun provides custom-tailored Deployment Support. Your Sun sales representative will be happy to discuss details of the offerings and assist you at selecting support option that best meets your needs. All customers as well as organizations currently evaluating Java RTS are also invited to participate in the Real-Time Specification for Java community where developers share ideas, questions and best practices on real-time programming in Java. Q: 18. Do evaluation versions of Java RTS have a reduced set of functional features relative to the production-use versions? No. The only way in which evaluation versions of Java RTS are different from their production-use counterparts, is that the former are limited to evaluation-use only (as described in the evaluation license agreement). Q: 19. I'm not a real-time developer or at least don't call myself one. Do I need special training to be able to use Java RTS? Yes and no. With some care, a developer can quickly take advantage of Java RTS features such as strict thread priorities and the RTGC by just changing the thread type (a simple substitution in the Java program code). However, most developers will want to do more than that and Sun has a solution. A 5-day, instructor-led hands-on programming class is offered through Sun Education. This course covers basic concepts and best practices for implementing real-time systems, as well as how to use the RTSJ interfaces effectively in the design of real-time applications. Download the course description (PDF). Q: 20. I want an integrated real-time solution - a full stack: hardware, operating environment, Java RTS, and possibly custom components. Can Sun provide this? In many cases, yes. Requests for a Java RTS-based integrated real-time solution are welcome and will be assessed. For industrial automation, Sun already has a first solution of this kind, sometimes referred to by its project name BlueWonder. For further information on how Sun can address your needs for an integrated real-time solution, please contact Java RTS Engineering and Marketing.
Q: 21. Can you provide a quick overview of the main technical features in Java RTS 2.2? The main technical features in Java RTS 2.2 are as follows:
Q: 22. Can I run Java RTS on a single-processor system? Yes. However, the maximum latency and jitter will be higher due to interrupt handling and cache effects. The latency numbers will vary more widely depending on processor speed and whether you are using one or multiple processors. The jitter number will vary primarily based on whether you are using one, or more than one processor. For example, our lab experience shows latency and jitter numbers of approximately 15 microseconds and 5 microseconds respectively on our reference platform (2x 1 GHZ UltraSPARC III processors). Turning off one processor results in latencies of about 50 microseconds +/- 30 microseconds. Note that these numbers are not absolute, but vary based on processor speed, number of processors, and amount of system memory. Q: 23. Are there advantages to using more memory or faster processors with Java RTS? Yes. Better throughput for both the non-real-time and hard real-time logic, and smaller maximum latency and jitter for the hard real-time logic. Typically, real-time systems have lower throughput than non-real-time systems, and this engineering trade-off is well known and accepted in the real-time community. Java RTS does, indeed, sacrifice throughput to get predictability. While on the surface this might seem to be a shortcoming, it actually isn't one at all. With Java RTS you have predictability, and essentially you can get more throughput by simply adding hardware. Moreover, it is important to realize that the inverse is NOT true: you cannot get predictability by adding hardware. Q: 24. Can I take code written for Java RTS and run it under another provider who supports the RTSJ specification? Mostly yes, but there are a few factors to consider:
Q: 25. What are the causes of jitter in my program? At the start of a program, jitter can be caused by class loading, class initialization, and Just-In-Time compilation. A little later in the execution, jitter can be caused by classes being lazily initialized or by bytecode being rewritten the first few times it is used. This type of jitter is reduced after this initialization stage. In addition, if the RTGC does not get enough CPU time to recycle memory, a thread can block when it tries to allocate memory. Q: 26. What diagnostic tools can I use with my Java RTS program? Are there developer tools for Java RTS? Yes. For example, Java RTS NetBeans module for debugging is available on the NetBeans site. The NetBeans module interfaces dynamically with a Java RTS program. It is, however, not an agent-based tool interacting with a running instance of Java RTS. (Use of agent-based tools interacting dynamically with Java RTS is, in principle, also possible but one should be aware that these can get confused when they encounter immortal or scoped memory or NHRTs.) Note: The first release of the NetBeans module targeted Java RTS 1.0 and was based on NetBeans 5.0. The second (current) release of the module targets Java RTS 2.0/2.1/2.2 and is based on NetBeans 5.5. With Java RTS, much more diagnostic tooling support became available, and Java RTS 2.2 extends this support. Java RTS on Solaris includes DTrace probe provider functionality, allowing real-time Java developers to monitor, troubleshoot, and tune their real-time applications. With the jrts DTrace Probe provider, it is possible to monitor activities from priority updates to memory area operations, as well as RTGC cycles, all without any modification to the running application. It is possible to synchronize a DTrace script with the start of the Java virtual machine, but a DTrace script can also be launched to monitor an already running virtual machine. The Thread Scheduling Visualizer (TSV) is a set of tools that provide an easy way to record and visualize thread scheduling for Java RTS 2.1 and 2.2 on Solaris. This tool set includes customizable DTrace scripts to record the scheduling events, as well as a visualizer to provide a graphical view of the events. The TSV tools set can be downloaded the same time you download a Java RTS evaluation. Q: 27. Does the key combination Control-Break work with Java RTS? Control-Break might work with Java RTS, but in any case it has a
significant impact on the system which causes it to disrupt the
NHRTs and the RTGC. In addition, this function does not yet include
information about Q: 28. What can cause synchronization delays? Synchronization delays are caused when the right thread is not running, because it is waiting for another thread. Q: 29. Are there any DTrace probes in Java RTS? Yes (see also questions 21 and 26). We have introduced substantial support for DTrace and Java RTS. Most of the major RTSJ features and operations have been instrumented, and probes have been added at critical places of the VM (locks, monitors and RTGC, notably). This remains work in progress, and new probes are added incrementally.
Q: 30. Can I run more than one real-time JVM instance at a time on my system? This approach is prone to undesired interferences between the JVMs due to, for example, contention for critical system resources controlling or affecting temporal behavior. Since it negatively impacts the temporal integrity, it should be avoided. Q: 31. What is the minimum configuration I need? You must specify the compilation method (see next question); otherwise your application will run in interpreted mode and will be slower than you might want it to be. You should also configure the RTGC (see question after next). Q: 32. Can the type of compilation used affect the execution of my program? Yes, you should use the compilation options to compile the time-critical code. By default, Java does things lazily. The classes are loaded, initialized, and compiled dynamically when needed for the first time. This creates non-determinism. Java RTS provides a compilation scheme to avoid dynamic compilation delays.
By default, the Just-In-Time (JIT) is used for Q: 33. Do I have to configure the Real-Time Garbage Collector? Yes, you should configure the RTGC to ensure that it gets enough CPU cycles. Configuring the RTGC means specifying its priority (through a command-line option) and specifying when it runs (through other command-line options). This is documented in the Garbage Collection Guide for the Java RTS product. On a multiprocessor machine, you could let the RTGC run continuously during the prototyping phase, by making it run at a very high priority and start even when the heap is nearly empty. Then, you can try to tune the RTGC by decreasing its priority and starting it later. However, if the RTGC does not have enough CPU time, threads might be blocked on allocation when the memory is exhausted. There are special command-line options that can be used to print GC information, which allows you to check whether the "worst" amount of available memory remains big enough. It is also possible to start the RTGC at a lower priority in order to use the idle CPU time and gradually increase its priority when memory consumption increases. The RTGC is fully concurrent, that is, it can recycle memory without stopping your threads. However, it must get enough CPU time to recycle memory faster than the threads consume it. At the same time, you need to find the balance between throughput and predictability (determinism). Since the RTGC works as a parallel process, when it runs it tries to use all the CPUs available. You can control the number of parallel RTGC threads with a command-line option that allows you to set the maximum number of CPUs. This is documented in the Garbage Collection Guide for the Java RTS product. Q: 34. What is a good ordering of the priorities? In general, good priority ordering is, from the most important to the least important:
A bound AEH might be more important than the timer thread, if you do not want it to be pre-empted by a time-triggered event. In any case, it is a good idea to explicitly set the priority for all the schedulables you create. Another view of priority levels is the following (again in descending order):
Q: 35. Why is my application so slow? If you did not specify any command-line compilation options, your application is running in interpreted mode. This has a side effect on the RTGC pause times, because interpreted frames are a bit more complex to process. Therefore, you should always try to compile the methods used by the time-critical threads if you want to minimize pause times. See also the question above concerning compilation configuration. Q: 36. Why does my throughput seem to be reduced? Java RTS provides advanced functionality and interfaces to tune predictability (determinism). For a given system configuration (hardware and OS), achieving higher predictability usually implies that some throughput must be sacrificed -- there is a trade-off between throughput and predictability. Whether a lower throughput is acceptable depends on specific user requirements. It is possible to accomplish both a higher predictability and a higher throughput by making appropriate changes to the system configuration, for example, by moving to a system with more processors and then taking advantage of a properly selected processor set. For this new configuration, there would again be a trade-off between predictability and throughput. (See also question 23.)
Q: 37. How can I quickly get started using Java RTS? First note that a given Java program written for the Java SE platform will
run fine on the Java RTS platform, as the latter implements not only the RTSJ
but the Java SE specification as well. However, observed throughput for the
Java RTS might be lower. A quick and easy conversion to the program will add
soft real-time behavior. This conversion involves creating
The priority of the To build a robust deterministic real-time system, you will need to do more
work. However, the above simple changes -- that is, basically just replacing
instances of See also the section "Getting Started with Java RTS" on the Sun Java Real-Time System 2.2 Technical Documentation web page. Q: 38. How many time constraints can an object have? Priority is driven by time constraints, so an object should have only one time constraint. Q: 39. Is there a way to reduce blocking between objects with different time constraints? If two connected objects have very dissimilar time constraints, consider adding a "timing transformer" as an additional thread. This new object can minimize blocking between objects. Q: 40. What is the purpose of immortal memory? Immortal memory is a non-garbage-collected area of memory. Once an object is allocated from immortal memory, the memory used by that object will never, in principle, be reclaimed. The primary use for immortal memory is the following: activities can avoid dynamic allocation by statically allocating all the memory they need ahead of time, and managing it themselves. Furthermore, the RTSJ requires that all static data and code of a class be allocated in immortal memory. Q: 41. How do I communicate an event outside the VM to Java RTS? There is a method to add an async handler to a POSIX signal. This is called a "happening." Q: 42. Can I use the concurrent API? The
Q: 43. Can I use the The timers provided by the Q: 44. How can I see what the RTGC is doing and when? There are special command-line options that can be used to print GC information. This will tell you whether and if so when the GC ran, and how long it took. Properly configure the RTGC to ensure it gets enough CPU time. (Specify its priority and specify when it starts.) On a multiprocessor machine, we recommend letting the RTGC run continuously during the prototyping, because this is the safest/easiest way to configure it. This is done by making it run at a very high priority and start even when the heap is nearly empty. Then, you can try to tune the RTGC, by decreasing its priority and starting it later. Just be careful that if the RTGC no longer gets enough CPU time, threads might be blocked on allocation when the memory is exhausted. (You should check that the "worst" amount of available memory remains big enough.) It is also possible to start the RTGC at a lower priority (to use the idle CPU time and gradually increase its priority when memory consumption increases). The JVM is instrumented to print different types of the GC-related jitter by specifying appropriate command-line flags. This is documented in the Garbage Collection Guide for the Java RTS product.
Q: 45. Can the RTGC work on memory in the regular heap with
The The only advantage of the RTGC is that, on a multi-processor machine,
it could run at the same time as your application thread, on another CPU.
If you run the GC at a higher priority than the In short, on a multiprocessor system, the RTGC can solve the jitter due to
the GC even for Q: 46. I'm concerned about real-time safety of using third-party libraries. How can I address this? There are some solutions/workarounds for this scenario, depending on applicable user requirements:
Case 1 above gets you much predictability and the advantages of real-time garbage collection, and many soft real-time applications will be fine using this design. Case 2 can be used for high throughput, low maximum latency transactions with careful coding Cases 3 and 4 are primarily meant for high frequency, very low maximum latency control loops. Q: 47. Is reflection supported in RTSJ? Yes, RTSJ supports the reflection classes. However, the caching mechanism
used in the reflection classes to boost performance can cause an
The use of the caching mechanism can be easily disabled by setting the
In addition, some reflection optimization code might cause an exception
with scoped memory because it changes a pointer towards a new
scope-allocated reflection object. To disable this optimization, you
can set the
Q: 48. I understand that NHRT can have no references to the standard heap,
and I thought I was creating arguments that are objects in
Use Q: 49. Can I use lazy instantiation of objects safely with Java RTS? Lazy instantiation can result in Java RTS objects being allocated from the
Java heap. You might have to change your Java program design to instantiate these
objects when the containing object is created, for example, in
Q: 50. Is the time returned via the real-time clock of better resolution than
that returned by The real-time clock and With Java RTS, all time-based APIs (for example, Timers, Periodic Threads,
Deadline Monitoring, and so forth) are based on the high-resolution timer.
And, together with real-time priorities, they can ensure that the appropriate
code will be executed at the right time for real-time constraints. In
contrast, ordinary Java SE APIs offer just a few methods capable of handling
high-resolution times, with no guarantee of execution at a given time.
Using |
Tell us what you think
Please take this short survey and let us know which features or enhancements you'd like to see included in future versions of Java RTS.
Real-Time Training
Java developers: Do you need better control of your Java applications? Learn the essential skills necessary to develop Real-Time systems using Java technology. Register online or call 1-800-422-8020. Related Real-Time ResourcesRelated ResourcesRelated DownloadsPopular Topics
Sun ResourcesRelated SitesGetting Started? | ||||||||||||
 | |
Oracle is reviewing the Sun product roadmap and will provide guidance to customers in accordance with Oracle's standard product communication policies. Any resulting features and timing of release of such features as determined by Oracle's review of roadmaps, are at the sole discretion of Oracle. All product roadmap information, whether communicated by Sun Microsystems or by Oracle, does not represent a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. It is intended for information purposes only, and may not be incorporated into any contract.
| ||||||||||||
