Platform Independent Timing of Java Virtual Machine Bytecode Instructions

The accurate measurement of the execution time of Java bytecode is one factor that is important in order to estimate the total execution time of a Java application running on a Java Virtual Machine. In this paper we document the difficulties and solutions for the accurate timing of Java bytecode. We also identify trends across the execution times recorded for all imperative Java bytecodes. These trends would suggest that knowing the execution times of a small subset of the Java bytecode instructions would be sufficient to model the execution times of the remainder. We first review a statistical approach for achieving high precision timing results for Java bytecode using low precision timers and then present a more suitable technique using homogeneous bytecode sequences for recording such information. We finally compare instruction execution times acquired using this platform independent technique against execution times recorded using the read time stamp counter assembly instruction. In particular our results show the existence of a strong linear correlation between both techniques.     

Java虚拟机中Java栈以及相关指令的实现

Java栈是Java虚拟机中运行时数据区的主要组成部分。大部分虚拟机指令的操作都与Java栈中的框架相关联。该文描述了Java栈在Java虚拟机运行中所起的作用,自行设计了一种Java栈的数据结构,提出了一些具有代表性的字节码指令的实现方法。同时总结了Java栈对虚拟机运行效率的影响。     

Type-directed weaving of aspects for polymorphically typed functional languages

Incorporating aspect-oriented paradigm to a polymorphically typed functional language enables the declaration of type-scoped advice, in which the effect of an aspect can be harnessed by introducing possibly polymorphic type constraints to the aspect. The amalgamation of aspect orientation and functional programming enables quick behavioral adaption of functions, clear separation of concerns and expressive type-directed programming. However, proper static weaving of aspects in polymorphic languages with a type-erasure semantics remains a challenge. In this paper, we describe a type-directed static weaving strategy, as well as its implementation, that supports static type inference and static weaving of programs written in an aspect-oriented polymorphically typed functional language, AspectFun. We show examples of type-scoped advice, identify the challenges faced with compile-time weaving in the presence of type-scoped advice, and demonstrate how various advanced aspect features can be handled by our techniques. Finally, we prove the correctness of the static weaving strategy with respect to the operational semantics of AspectFun.     

Orthogonal persistence in nonvolatile memory architectures: A persistent heap design and its implementation for a Java Virtual Machine

Current computer systems separate main memory from storage, and programming languages typically reflect this distinction using different representations for data in memory and storage. However, moving data back and forth between these different layers and representations compromise both programming and execution efficiency. To remedy this, the concept of orthogonal persistence (OP) was proposed in the early 1980s advocating that, from a programmer's standpoint, there should be no differences in the way that short-term and long-term data are manipulated. However, at that time, the underlying implementations still had to cope with the complexity of moving data across memory and storage. Today, recent nonvolatile memory (NVM) technologies, such as resistive RAM and phase-change memory, allow main memory and storage to be collapsed into a single layer of persistent memory, opening the way for more efficient programming abstractions for handling persistence. In this work, we revisit OP concepts in the context of NVM architectures and propose a persistent heap design for languages with automatic memory management. We demonstrate how it can significantly increase programmer and execution efficiency, removing the impedance mismatch of crossing semantic boundaries. To validate and demonstrate the presented concepts, we present JaphaVM, an implementation of the proposed design based on JamVM, an open-source Java Virtual Machine. Our results show that JaphaVM, in most cases, executes the same operations between one and two orders of magnitude faster than regular database-based and file-based implementations, while requiring significantly less lines of code.     

On the design of global object space for efficient multi-threading Java computing on clusters

The popularity of Java and recent advances in compilation and execution technology for Java are making the language one of the preferred ones in the field of high-performance scientific and engineering computing. A distributed Java Virtual Machine supports transparent parallel execution of multi-threaded Java programs on a cluster of computers. It provides an alternative platform for high-performance scientific computations. In this paper, we present the design of a global object space for a distributed JVM. It virtualizes a single Java object heap across machine boundaries to facilitate transparent object accesses. We leverage runtime object connectivity information to detect distributed shared objects (DSOs) that are reachable from threads at different nodes to facilitate efficient memory management in the distributed JVM. Based on the concept of DSO, we propose a framework to characterize object access patterns, along three orthogonal dimensions. With this framework, we are able to effectively calibrate the runtime memory access patterns and dynamically apply optimized cache coherence protocols to minimize consistency maintenance overhead. The optimization devices include an object home migration method that optimizes the single-writer access pattern, synchronized method migration that allows the execution of a synchronized method to take place remotely at the home node of its locked object, and connectivity-based object pushing that uses object connectivity information to optimize the producer–consumer access pattern. Several benchmark applications in scientific computing have been tested on our distributed JVM. We report the performance results and give an in-depth analysis of the effects of the proposed adaptive solutions.     

A Type System for the Java Bytecode Language and Verifier

The Java Virtual Machine executes bytecode programs that may have been sent from other, possibly untrusted, locations on the network. Since the transmitted code may be written by a malicious party or corrupted during network transmission, the Java Virtual Machine contains a bytecode verifier to check the code for type errors before it is run. As illustrated by reported attacks on Java run-time systems, the verifier is essential for system security. However, no formal specification of the bytecode verifier exists in the Java Virtual Machine Specification published by Sun. In this paper, we develop such a specification in the form of a type system for a subset of the bytecode language. The subset includes classes, interfaces, constructors, methods, exceptions, and bytecode subroutines. We also present a type checking algorithm and prototype bytecode verifier implementation, and we conclude by discussing other applications of this work. For example, we show how to extend our formal system to check other program properties, such as the correct use of object locks. This revised version was published online in August 2006 with corrections to the Cover Date.     

A Platform-Independent Distributed Runtime for Standard Multithreaded Java

JavaSplit is a portable runtime environment for distributed execution of standard multithreaded Java programs. It gains augmented computational power and increased memory capacity by distributing the threads and objects of an application among the available machines. Unlike previous works, which either forfeit Java portability by using a nonstandard Java Virtual Machine (JVM) or compromise transparency by requiring user intervention in making the application suitable for distributed execution, JavaSplit automatically executes standard multithreaded Java on any heterogenous collection of Java-enabled machines. Each machine carries out its part of the computation using nothing but its local standard (unmodified) JVM. Neither the programmer nor the person submitting the program for execution needs to be aware of JavaSplit or its distributed nature. We evaluate the efficiency of JavaSplit on several combinations of operating systems, JVM implementations, and communication hardware.     

A distributed implementation of a virtual machine for Java

The cluster virtual machine (VM) for Java provides a single system image of a traditional Java Virtual Machine (JVM) while executing in a distributed fashion on the nodes of a cluster. The cluster VM for Java virtualizes the cluster, supporting any pure Java application without requiring that application be tailored specifically for it. The aim of our cluster VM is to obtain improved scalability for a class of Java Server Applications by distributing the application's work among the cluster's computing resources. The implementation of the cluster VM for Java is based on a novel object model which distinguishes between an application's view of an object (e.g. every object is a unique data structure) and its implementation (e.g. objects may have consistent replications on different nodes). This enables us to exploit knowledge on the use of individual objects to improve performance (e.g. using object replications to increase locality of access to objects). We have already completed a prototype that runs pure Java applications on a cluster of NT workstations connected by a Myrinet fast switch. The prototype provides a single system image to applications, distributing the application's threads and objects over the cluster. We used the cluster VM to run, without change, a real Java Server Application containing over 10 Kloc

1 Kloc means Kilo lines of code—used to describe the size of applications in terms of source lines count.

for the source code and achieved high scalability for it on a cluster. We also achieved linear speedup for another application with a large number of independent threads. This paper discusses the architecture and implementation of the cluster VM. It focuses on achieving a single system image for a traditional JVM on a cluster while describing, in short, how we aim to obtain scalability. Copyright © 2001 John Wiley & Sons, Ltd.     

基于垃圾收集的Java程序性能改善方法*

JVM中堆的默认配置有时并不适用于大型程序,这会使系统在垃圾收集上耗费过多的时间,进而导致程序性能下降。简要分析了HotSpot JVM垃圾收集机制,然后结合已有研究,以一个网管程序为例,提出了通过调整垃圾收集提高程序运行效能的方法。     

基于嵌入式Java虚拟机的垃圾收集优化算法

对分代垃圾收集算法进行分析和改进,提出一种适用于嵌入式Java虚拟机的垃圾收集优化算法。采取动态的分代方式,将旧生代的回收工作细分,从而充分利用堆空间,缩短分代回收中全收集导致的停顿时间。实验结果表明,该算法能保持较高的垃圾收集效率,系统平均停顿时间较少。     

64‐bit versus 32‐bit Virtual Machines for Java

The Java language is popular because of its platform independence, making it useful in a lot of technologies ranging from embedded devices to high‐performance systems. The platform‐independent property of Java, which is visible at the Java bytecode level, is only made possible thanks to the availability of a Virtual Machine (VM), which needs to be designed specifically for each underlying hardware platform. More specifically, the same Java bytecode should run properly on a 32‐bit or a 64‐bit VM. In this paper, we compare the behavioral characteristics of 32‐bit and 64‐bit VMs using a large set of Java benchmarks. This is done using the Jikes Research VM as well as the IBM JDK 1.4.0 production VM on a PowerPC‐based IBM machine. By running the PowerPC machine in both 32‐bit and 64‐bit mode we are able to compare 32‐bit and 64‐bit VMs. We conclude that the space an object takes in the heap in 64‐bit mode is 39.3% larger on average than in 32‐bit mode. We identify three reasons for this: (i) the larger pointer size, (ii) the increased header and (iii) the increased alignment. The minimally required heap size is 51.1% larger on average in 64‐bit than in 32‐bit mode. From our experimental setup using hardware performance monitors, we observe that 64‐bit computing typically results in a significantly larger number of data cache misses at all levels of the memory hierarchy. In addition, we observe that when a sufficiently large heap is available, the IBM JDK 1.4.0 VM is 1.7% slower on average in 64‐bit mode than in 32‐bit mode. Copyright © 2005 John Wiley & Sons, Ltd.