Michael H. Dawson

Design and implementation of a comprehensive real-time java virtual machine

The emergence of standards for programming real-time systems in Java has encouraged many developers to consider its use for systems previously only built using C, Ada, or assembly language. However, the RTSJ standard in isolation leaves many important problems unaddressed, and suffers from some serious problems in usability and safety. As a result, the use of Java for real-time programming has continued to be viewed as risky and adoption has been slow. In this paper we provide a description of IBMs new real-time Java virtual machine product, which combines Metronome real-time garbage collection, ahead-of-time compilation, and a complete implementation of the RTSJ standard, running on top of a custom real-time multiprocessor Linux kernel. We will describe the implementation of each of these components, including how they interacted both positively and negatively, and the extensions to previous work required to move it from research prototype to a system implementing the complete semantics of the Java language. The system has been adopted for hard real-time development of naval weapons systems and soft real-time telecommunications servers. We present measurements showing that the system is able to provide sub-millisecond worst-case garbage collection latencies, 50 microsecond Linux scheduling accuracy, and eliminate non-determinism due to JIT compilation.

Challenges in Implementing the Real-Time Specification for Java (RTSJ) in a Commercial Real-Time Java Virtual Machine

The increasing complexity of modern real-time systems and the increasing need for real-time behavior in a broad range of applications such as network- centric warfare, telephony and stock trading has encouraged many developers to consider using Real-time Javatrade for systems previously only written in C, Ada or assembly language. The RTSJ standard defines the baseline requirements for a Real-time Java implementation, and commercial Java virtual machine (JVM) implementations include additional features such as real-time garbage collectors and real-time compilation (compiling from Java to native code in a manner compatible with real-time), which make the use of Java practical for these applications. This paper describes some of the challenges that will be faced by implementers of the RTSJ standard based on our experience with implementing IBMs RTSJ-compliant J2SE Java virtual machine, called IBMreg WebSpherereg Real-time.

Dynamic monitor allocation in the Java virtual machine

With the Java language and sandboxed environments becoming more and more popular research needs to be conducted into improving the performance of these environments while decreasing their memory footprints. In this paper we present a dynamic approach for growing monitors for objects in order to reduce the memory footprint and improve the execution time of the IBM Java Virtual Machine. According to the Java Language Specification every object needs a monitor, however not all objects require synchronization, thus the monitor can have a negative memory impact. Our new approach grows monitors only when required. The impact of this approach on performance and memory has been evaluated using the SPECjbb2005 benchmark and future work is also discussed. On average a performance increase of 0.47% and a memory reduction of about 5.51% has been achieved with our approach.

A Java util concurrent park contention tool

Java Util Concurrent (JUC) is a widely used library in multithreaded Java applications. JUC provides a variety of tools such as locks, thread pools and blocking queues. Many of these constructs use Thread Park, a mechanism which allows threads to be blocked from execution, as a means of thread synchronization. We modified the IBM Java Virtual Machine (JVM) creating a near zero overhead tool that measures and reports park contention data using a variety of metrics. This information can then be used to identify bottlenecks and consequently accelerate Java code. We demonstrate the usefulness of this JUC Park Contention Tool in two example code patterns where it successfully identifies the JUC lock bottleneck. Furthermore, we also compare theoretical with measured values of the metrics in an example program. Finally, we use our tool to profile the Java benchmarks SPECjbb2005, SPECjbb2013 and the DaCapo benchmark suite.

A Tool for Scalable Profiling and Tracing of Java and Native Code Interactions

Java workloads have two different execution spaces: one in JVM and the other in the native environment. Understanding workload activity in native and non-native (Java) spaces and its impact on the overall resource consumption of Java workloads can be very useful. For example, this knowledge can be exploited in code optimization and for efficient process level scheduling especially in emerging hybrid systems. Existing Java run time tracing tools are quite heavyweight and/or offer limited useful information for understanding Java and native space interactions. We developed an extremely lightweight tracing tool for enterprise Java workloads. The tool captures detailed per-thread statistics related to resource usage and activity in JVM and native spheres. Efficient design based on innovative thread and memory management principles enables us to achieve scalable monitoring with our tool on multi-core systems running enterprise workloads. The information captured by the tool is used to build workload profiles which can then be used for predictive performance of Java workloads in emerging systems and architectures.

Testing class libraries for RTSJ safety

The addition of new thread types and new memory areas by the Real-Time Specification for Java#8482; (RTSJ) [1] introduces new failure modes for existing class libraries. Existing tests for these class libraries will not cover execution with RTs, NHRTs and with the Immortal and Scoped memory areas. Writing new tests to cover these new cases can take significant time and effort. This paper introduces an approach we call AutoRTUnit that allows us to get test coverage for the new thread types and memory areas by reusing existing JUnit[2] based unit tests. In our case we applied it to expand our test coverage for a subset of the non-RTSJ APIs within our RTSJ-compliant Java virtual machine (JVM).

Experiences in building and scaling an enterprise application on multicore systems

Even though Java is the de facto programming language for enterprise applications, there exist only a limited number of Java‐based benchmarks to understand the performance on emerging multicore systems. To bridge this gap, this paper presents a report generation benchmark that is developed on top of Open Source Apache Geronimos DayTrader benchmark. Report generation and rendering is at the heart of many enterprise business analytics and business intelligence software products, and it is used by many enterprise applications. We evaluate the performance scalability of this benchmark on a state‐of‐the‐art Power7 multicore system with 8 Power7 cores and 32 hardware threads. The benchmark throughput scales linearly up to eight hardware threads, but beyond that point, the throughput falls sharply. Significant locking in the Java class libraries for non‐shared objects results in this performance drop. Splitting the locks on these shared classes results in near linear scaling from eight to 32 threads and improved the throughput by 80%. We also show that the Linux operating system load balancing could result in a degraded application performance in hardware multithreaded systems and simultaneous‐multithreads‐aware task scheduling results in uniform core‐resource utilization as well as improved application performance. Copyright

Dynamically Compiled Artifact Sharing for Clouds

Platform as a Service (PaaS) clouds provide part of the hardware/software stack and related services to tenant applications. Increased load is handled elastically by scaling, which either modifies the number of instances an application has available on the cloud or increases their available resources. However, because all these instances run inside isolated containers, experience gained by the first instance of an application cannot be easily shared with subsequent scaled instances. This results in both increased startup time and response timeout errors for the scaled instances as well as increased performance interference for any co-located applications; reacquiring this experience is a time-consuming and resource-intensive process. We propose a scalable and secure technique to share dynamically compiled artifacts produced by the first execution instance of an application and otherwise created for intra-OS sharing only with subsequent scaled or restarted instances as a solution to these problems. Our solution abides by the usual PaaS limitations and uses a distributed and containerized cloud service, which we experimentally show to be scalable on a Docker Swarm running on top of a 6-VM cluster; also, we discuss the results of a usability survey for the services GUI conducted with expert subjects. The effectiveness of the DCAS technique was experimentally tested on an isolated installation of the PaaS software Cloudy Foundry; we measured significant reductions in both the startup time and response errors of scaled out instances as well as performance interference to co-located tenants during scaling.

Investigating the Effect of Garbage Collection on Service Level Objectives of Clouds

Platform as a Service (PaaS) clouds abstract large parts of the hardware/software stack to its tenant clients and provide it as a service. In this paper, we highlight the lack of scientific literature on the problem of Service Level Objective (SLO) satisfaction effects on clouds due to Garbage Collection (GC). To this end, we propose and implement CloudGC, a configurable PaaS application framework that aims in stressing the GC component of the underlying runtime. We use our CloudGC to experimentally evaluate the performance of the four GC policies (Gencon, Balanced, Optavgpause and Optthroughput) available in the IBM J9 Java Runtime, running on top of a local and isolated installation of the PaaS software Cloud Foundry.