 |
This document summarizes the functionality and issues of the
Sun Java™ Real-Time System (Java RTS) 2.2.
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 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 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)
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 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.22-rt.)
Red Hat Enterprise MRG 1.1 Errata (released and supported)
http://www.redhat.com/mrg
(Note: The Java RTS 2.2 criteria were met on the Red Hat MRG 1.1 Errata release with the
2.6.24.7-126.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.
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 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.1 Errata, Java RTS 2.2 for Linux is impacted by the following bugs,
which cause determinism/performance issues:
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:
[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 is generally based on the Java Platform, Standard Edition
(Java™ SE) version 5.0 Update 20.
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 20 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.
We are aware of the CR 6682380 (Foreach loop with generics inside finadiffslly block crashes javac with -target 1.5).
This is a compiler bug, which is fixed in a future version of Java SE.
(See http://bugs.sun.com/view_bug.do?bug_id=6682380.)
[Contents]
Enhancements in This Java RTS Release
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 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]
Copyright © 2009 Sun Microsystems, Inc. All Rights Reserved.
|
|
