This document summarizes the functionality and issues of the Sun Java™ Real-Time System (Java RTS) 2.2 Update 1. To ensure that you have the most recent update of this document, check the latest version on the Java SE Real-Time Product Documentation web site.

Java RTS is Sun's implementation of the Real-Time Specification for Java (RTSJ). The specification details for this implementation are described in Java RTS Implementation Details.

Java RTS 2.2 Update 1 complies with JSR-01 Technology Compatibility Kit (TCK) 1.0.2 version SE 3.0.14, which tests the behavior of implementations of RTSJ version 1.0.2.

Technical Documentation: Links to all the Java RTS technical documents

Contents

Operating System Support for Solaris OS
Operating System Support for Linux OS
Known Issues
Java Virtual Machine Support
Functionality and Issues of Java SE 5.0
Enhancements in This Java RTS Release
General Differences from Java HotSpot VM
Functionality and Issues Specific to Java RTS
Contact Us

Operating System Support for Solaris OS

Java RTS 2.2 Update 1 is supported on an UltraSPARC® processor or on a x86/x64 platform running one of the following operating systems:

• Solaris™ 10 Operating System update 6, also called Solaris 10 10/08 (OS kernel version Generic_137138-09 on x86, Generic_137137-09 on SPARC)

• Solaris™ 10 Operating System update 7, also called Solaris 10 5/09 (OS kernel version Generic_139556-08 on x86, Generic_139555-08 on SPARC)

• Solaris™ 10 Operating System update 8, also called Solaris 10 10/09 (OS kernel version Generic_141445-09 on x86, Generic_141444-09 on SPARC)

Refer to the content of the /etc/release file to determine the exact version of Solaris that is installed on your machine.

The OS kernel version is reported by the command uname -v.

Note: Drivers are specific to a particular version of the Solaris 10 Operating System. If you attempt to install a package on a version of Solaris 10 OS where it is not certified, that is, not in the above list, you will receive a warning message. You can continue the installation on that version, but such an installation constitutes an unsupported configuration. In this case, incompatibilities in the cyclic driver package and Solaris 10 OS version may adversely affect the behavior of the operating system.

Operating System Support for Linux OS

Java RTS 2.2 Update 1 was tested on the x86/x64 platform running one of the following operating systems:

• SUSE Linux Enterprise Real Time 10 Service Pack 2 (SP2) update 6 (released and supported)
  http://www.novell.com/products/realtime/
  (Note: Linux kernel version should begin with "2.6.22". The supported version is 2.6.22.19-0.35-rt.)

• Red Hat Enterprise MRG 1.2 (released and supported)
  http://www.redhat.com/mrg
  (Note: The Java RTS 2.2 Update 1 criteria were met on the Red Hat MRG 1.2 release with the 2.6.24.7-139.el5rt Linux kernel version.)

Our initial test and support plans do not include other Linux distributions. However, since this release of Java RTS uses the real-time POSIX programming interface, it is possible that other properly configured Linux distributions that implement this interface can also run Java RTS 2.2 Update 1. Temporal correctness is still being worked on by the Linux community, but currently the OS configuration needs to include a 2.6.21 Linux kernel or later with the latest RT patch. (See the site http://www.kernel.org/pub/linux/kernel/projects/rt/ to obtain the appropriate RT patch.) In addition, Java RTS will not run on a system with a glibc version prior to 2.4; furthermore, to reduce issues with priority inversion, Java RTS needs either a system with glibc 2.5 or later, or else a system that has explicitly patched glibc with the necessary priority-inheritance mutex support from 2.5.

[Contents]

Known Issues

This section provides certain known issues that could possibly impact your application.

SUSE Linux Issues

With SUSE Linux Enterprise Real Time 10 Service Pack 2 (SP2), Java RTS 2.2 Update 1 for Linux is impacted by the following bugs, which cause determinism/performance issues:

• Bug 351645 - pthread mutexes/condvars process private attribute not passed to kernel futex calls
  (https://bugzilla.novell.com/show_bug.cgi?id=351645)

  Bug 354746 - fix pthread_cond_timedwait so that it uses absolute time FUTEX_WAIT command
  (https://bugzilla.novell.com/show_bug.cgi?id=354746)

  Novell provides a fix to these problems with an alternate libpthread library installed in /opt/novell/glibc2.4-nptl2.7/lib/libpthread.so.0 (32-bit version) or /opt/novell/glibc2.4-nptl2.7/lib64/libpthread.so.0 (64-bit version) as part of the package libpthread-alt. If the application is run with the Java RTS launchers, then this alternate libpthread, if available, is used. If the JVM is embedded in the application, then the application must explicitly preload this library. Note that if you are running on a 64-bit system and running the 32-bit version of Java RTS, you must install the 32-bit version of the library, namely libpthread-alt-32bit.

  On a 64-bit system, if the application is 32-bit and spawns a 64-bit process (for example, with Runtime.exec()), error messages reporting failed attempts to preload libpthread.so.0 might appear. These messages can be ignored.

  At the time of this writing, the latest version of the alternate libpthread library packages is 0.13. You must ensure that you are using this version (or a later one), as previous versions contained a bug that made them unusable with Java RTS; please see Bug 498699 - pthread_cond_timedwait does a busy-wait using alternate libpthread on 32-bit (https://bugzilla.novell.com/show_bug.cgi?id=498699).

  To see which version of the native (32-bit on 32-bit, 64-bit on 64-bit) alternate libpthread you have installed, use the following command:

   # rpm -q libpthread-alt-2.4nptl27
  

  To see which version of the 32-bit alternate libpthread you have installed on a 64-bit system use the following command:

  # rpm -q libpthread-alt-32bit-2.4nptl27
  

• Bug 366853 - mmap may keep mmap_sem for a long time
  (https://bugzilla.novell.com/show_bug.cgi?id=366853)

• Bug 372898 - Libc's implementation of condition variables subject to priority inversion
  (https://bugzilla.novell.com/show_bug.cgi?id=372898)

Red Hat Linux Issues

With Red Hat Enterprise MRG 1.2, Java RTS 2.2 Update 1 for Linux is impacted by the following bugs, which cause determinism/performance issues:

• Bug 400981: pthread mutexes/condvars process private attribute not passed to kernel futex calls
  (https://bugzilla.redhat.com/show_bug.cgi?id=400981)

  This issue has been seen to cause latencies of up to one millisecond. Because the pthread_mutex and pthread_condvar are not marked as process-private, their use requires synchronization through the mmap semaphore. This semaphore is also used for a number of memory-management related operations; therefore, for example, a real-time thread can be blocked from returning from a mutex or condvar operation until another thread (possibly non-real-time) completes a memory operation.

• Bug 429292: fix pthread_cond_timedwait so that it uses absolute time FUTEX_WAIT command
  (https://bugzilla.redhat.com/show_bug.cgi?id=429292)

• Bug 435721: mmap may keep mmap_sem for a long time
  (https://bugzilla.redhat.com/show_bug.cgi?id=435721)

• Bug 435734: page fault handling may keep mmap_sem for a long time
  (https://bugzilla.redhat.com/show_bug.cgi?id=435734)

• Bug 438484: Libc's implementation of condition variables subject to priority inversion
  (https://bugzilla.redhat.com/show_bug.cgi?id=438484)

• Bug 554965: gcore tool produces unusable corefile with MRG kernel
  (https://bugzilla.redhat.com/show_bug.cgi?id=554965)

  The Java RTS 2.2 Update 1 release supports the MRG 1.2 kernel 2.6.24.7-139.el5rt. However, with this kernel, the gcore tool produces core files that are unusable. This problem did not exist with the MRG 1.1 kernel 2.6.24.7-126.el5rt. If you need to generate a core file on demand in order to use the Java RTS Service Availability tools, then you should use the MRG 1.1 kernel 2.6.24.7-126.el5rt.

Issue with calloc Function

The libc function calloc is broken in some glibc versions. Java RTS redefines calloc in the dynamic library <path to Java RTS>/jre/lib/i386/libcalloc.so and works around the issue by preloading this library at VM startup. Thus a user application is not impacted by this problem unless it does not use the Java RTS launchers and embeds the JVM. In this case, the application must redefine calloc, for example, by explicitly linking with the libcalloc.so that is provided by Java RTS.

On a 64-bit system, if the application spawns a 64-bit process (for example, with Runtime.exec()), error messages reporting failed attempts to preload libcalloc.so might appear. These messages can be ignored.

Issue with DTrace Timestamps

(Solaris OS only) When DTrace is used to monitor the Java RTS VM, timestamps produced by DTrace can sometimes have wrong values due to the following bugs:

• Bug 6507659: tsc differences between CPU's give dtrace_gethrtime() serious problems
  (http://bugs.opensolaris.org/view_bug.do?bug_id=6507659)

• Bug 6600939: gethrtime sometimes return a large time value into the future
  (http://bugs.opensolaris.org/view_bug.do?bug_id=6600939)

Issue with Xsun and Xorg X11 Servers on Solaris

The Xsun(1) Solaris server for X version 11, for SPARC and x86 systems, and the Xorg(1) X11R7 X server, for x86 systems, can load a module known as the "SolarisIA" or "IA" module. This module is always loaded in Xsun but is configurable for Xorg via the xorg.conf(1) configuration file. The purpose of the "SolarisIA" module is to run X11 client processes in the Solaris operating system's IA (interactive) scheduling class. This occurs whenever a program running on the same host as the X server calls XOpenDisplay(), and it affects all threads executing in the program at that time.

For a Java RTS application, many internal VM threads (including the RTGC), and all application-defined real-time threads, execute in the RT (real-time) scheduling class. This means that the use of the "SolarisIA" module will cause those threads to lose their real-time scheduling properties and consequently will severely impact the deterministic execution of the application and the VM. These threads will return to the RT scheduling class if they subsequently have their priority set, either explicitly, or implicitly due to priority-inheritance.

To ensure deterministic execution of a Java RTS application, that uses X11 for its graphical user interface, you must prevent the "SolarisIA" module from being used. This can be achieved by one of the following means:

• Using a local X server other than Xsun or Xorg
• Using the Xorg X11R7 server with the "SolarisIA" module not loaded.

  This is done by deleting the applicable line in the Xorg configuration file's Module section, e.g.:

  Section "Module"
          Load  "IA"  

  Please consult the Xorg(1) and xorg.conf(1) manpages for information on how to locate or create the configuration file used.
• Using a remote X server

Note that if your Java RTS application does not use a graphical user interface, it is not affected even if the local X server is using the "SolarisIA" module.

[Contents]

Java Virtual Machine Support

Java RTS provides the 32-bit or 64-bit "client" version of the Java virtual machine; using the -server option has no effect.

For the best temporal performance, we recommend installing Java RTS on a machine featuring at least two processors.

[Contents]

Functionality and Issues of Java SE 5.0

Java RTS 2.2 Update 1 is generally based on the Java Platform, Standard Edition (Java™ SE) version 5.0 Update 22. Java SE 5.0 (also known as J2SE™ 5.0 or 1.5.0) is a major release of the Java platform containing new features and enhancements in many functional areas. Update releases are bug fix releases, which can include reliability, performance, and security fixes. The features, bugs, and workarounds of the Java SE 5.0 release and the additional fixes provided by Update 22 can be found at the J2SE 5.0 Release Notes web site.

Java SE 5.0 supports a facility known as Class Data Sharing. CDS is only enabled when the client compiler and the serial Garbage Collector are used. Although Java RTS provides both the client compiler and serial Garbage Collector, it does not support the use of Class Data Sharing.

The Java Platform API for the Thread class contains a number of deprecated methods dating back to the introduction of the Java 2 Platform in JDK 1.2. This deprecated functionality has minimal support in the platform and need not be extended to apply to the javax.realtime.RealtimeThread and javax.realtime.NoHeapRealtimeThread classes introduced by the RTSJ. In particular, in Java RTS, the Thread.suspend method has no effect on instances of javax.realtime.NoHeapRealtimeThread.

[Contents]

Enhancements in This Java RTS Release

Changes in Java RTS 2.2 Update 1

Java RTS 2.2 Update 1 provides the following enhancements to the previous version:

Changes in Java RTS 2.2

Java RTS 2.2 provides the following enhancements to the previous version:

• Support for applications running on 64-bit systems (in addition to 32-bit support). For a 64-bit VM on Solaris OS, add the -d64 option to the command line when launching the VM.

• Improvements in the Real-Time Garbage Collector functionality:

  • A new analytical auto-tuning algorithm, based on statistics, for RTGC startup. This new mechanism is activated by default, and the old "sliding-value" mechanism is deactived by default.

  • A new parameter to specify the amount of free memory that is targeted by the auto-tuning mechanisms. The RTGC should start soon enough so that this level is never reached.

  • A new parameter to specify an initial minimum free memory level for starting the RTGC.

  • The auto-tuning for boosted mode is now deactived by default.

  • The default number of RTGC workers, RTGCNormalWorkers and RTGCBoostedWorkers, have been reduced.

  See the Java RTS Garbage Collection Guide for details.

• New Initialization-Time-Compilation (ITC) options. You can now specify the type of thread for which methods will be precompiled. You can also use wild cards in the precompilation list to specify the class name, method name, or method signature. See the Java RTS Compilation Guide.

• In Java RTS 2.1 the VM would first try to acquire all the memory it needed (heap, scope backing store, immortal memory, and so forth) and then request the locking of all that memory. If this locking failed, then the VM simply issued a warning to the standard error stream and continued. This could result in the application executing non-deterministically due to memory page swapping.

  In Java RTS 2.2 this behavior has been changed. The VM first requests the locking of all memory pages that are currently used and that will be used in the future. Then it tries to acquire the needed regions of memory. If any of these acquisitions fails, then initialization of the VM will terminate. If the user wishes to continue with the requested memory sizes, then the -XX:-RTSJLockPagesInMemory option can be used to disable memory locking. In this way less physical memory will be needed, but memory accesses will be non-deterministic due to virtual memory swapping. This change ensures that the VM behaves non-deterministically only if explicitly requested by the user.

  See Memory Locking in the Technical Information Guide for more details.

• The technical documentation includes a new Java RTS Quick Start Guide to help users get started quickly with Java RTS, with a minimum of programming and configuration.

• Minor bug fixes and clean-up.

[Contents]

General Differences from Java HotSpot VM

General differences in the behavior of Java RTS as compared with the Java HotSpot™ Virtual Machine are as follows:

• The Java HotSpot VM defines a large number of unsupported, but often well known, command-line options that can affect its behavior in various ways. Many of these options are incompatible with the Java RTS VM and should not be used. See the Java RTS Command-Line Options document for the available options with Java RTS.

• The default values for the command-line parameters have been tuned for Java RTS and might differ from the default values in the Java HotSpot VM. For example, the default values for -Xms and -Xmx have been increased for Java RTS.

• The -Xms and -Xmx heap-sizing options do not operate the same way in Java RTS as they do in regular HotSpot. In Java RTS the heap does not grow from the minimum requested size (-Xms) up to the maximum (-Xmx), as this would cause extreme jitter and non-determinism. In Java RTS the maximum requested heap size is always allocated at VM initialization.

  For the same reasons, the XX:-PermSize and -XX:MaxPermSize permgen-sizing options do not operate the same way in Java RTS as they do in regular HotSpot. In Java RTS the permanent generation is not allowed to grow dynamically. Therefore, at VM initialization -XX:PermSize is set to the value of -XX:MaxPermSize.

• All memory used by the VM is locked when the VM is initialized. This places a greater demand on the physical memory installed on a system, as virtual memory is not utilized by the VM. See Memory Locking in the Technical Information Guide for more details.

• Java RTS has limited support for the monitoring, management, and troubleshooting tools. See the Java RTS Tools, Tuning, and Troubleshooting Guide.

• Because of NoHeapRealtimeThreads, the RTSJ states that certain (potentially) shared objects must never be garbage collected. This includes Class objects, string literals, interned strings, and all objects created as part of static initialization. You should be aware that such objects are allocated in immortal memory and survive until the JVM exits. This precludes class unloading from occurring, and can also lead to unexpected out-of-memory conditions. See, for example, Shared Objects in Immortal Memory in the Technical Information Guide.

• The Real-Time Garbage Collector has to expend more effort in reclaiming garbage than other, non-real-time, garbage collectors. To ease its workload you should avoid coding practices that can lead to excessive, and unnecessary, garbage production. See Reducing Unnecessary Garbage Production in the Technical Information Guide for more details.

• The only compiler that Java RTS provides is the client compiler. The server compiler depends on non-deterministic optimization and has therefore been deactivated.

• Just-In-Time (JIT) compilation is asynchronous by default. See the Compilation Guide for details.

• Java RTS provides the implementation of variants of inline caches and virtual method inlining. These variants allow balancing throughput and determinism when using the Real-Time Garbage Collector. See the Compilation Guide for details.

• Java RTS does not support the Java™ Virtual Machine Profiler Interface (JVMPI).

[Contents]

Functionality and Issues Specific to Java RTS

Java RTS differs in functionality from Java SE and the Java HotSpot VM in a number of areas, including clocks, timers, class initialization, memory management, and scheduling. In addition, certain issues, such as programming considerations, limitations, bugs, and workarounds, are applicable only to Java RTS. The Technical Information document summarizes the functionality and issues that are specific to Java RTS.

[Contents]

Contact Us

Please report any problems or bugs you might encounter to the Java RTS team.

[Contents]