Runtime Code Update is a technique to update a program while it is running. Such a feature is often used so the developer can modify an application without the necessity to restart the application and recover desired state after restart. This saves time and lowers costs. Furthermore, there are applications which cannot be stopped, such as air traffic control systems or telephone switches. Current virtual machines for Java programming language do not support non-trivial updates to the running code. We have modified STX:LIBJAVA - an implementation of Java virtual machine within Smalltalk/X - to support arbitrary changes to the running code. Beside changes to the fields and methods which are already supported by the tools such as JRebel or Javaleon, we also support unrestricted changes to the class and interface hierarchy. Our Runtime Code Updates scheme has been integrated into the Smalltalk/X IDE, thus providing interactive environment where a developer can modify a Java application while it is running.
The ability to dynamically update the code of a running application is interesting for many domains. It can reduce downtime of long-running systems by eliminating the need for stopping, redeploying and starting the application again. There are applications that have to be maintained and improved but cannot be stopped. Financial transaction processors, telephone switches, air traffic control systems, are all examples of such applications.
Dynamic code updates can improve programmer productivity during programming
by giving instant feedback without the need to wait for rebuild and deployment (Shan
[
Updating the code of the running program has been researched in the past (Fabry
[
There are approaches for some types of runtime code updates for Java including: JRebel4 and Javaleon5 – an application-level systems; Dynamic Code Evolution VM 6 – a modification of the HotSpot VM allowing runtime code changes; JVolve7 – a solution based on the Jikes Research VM.
None of existing solutions supports all types of runtime code updates. HotSpot VM has not been developed with runtime code updates in mind and has to be modified to support this feature. Such modification requires a large amount of engineering work.
In this paper we present STX:LIBJAVA – a Java VM implementation for Smalltalk/X VM – which has been modified to support all types of runtime code updates for Java. We show solutions and implementation details which relate to the runtime code updates which may be relevant to all Java virtual machines.
The contributions of this paper are (i) presentation of the system supporting all types of runtime code updates for Java, (ii) identification of problems related to runtime code update support in STX:LIBJAVA and (iii) description of solutions to runtime code update problems in STX:LIBJAVA.
The paper is organized as follows: Section 2 describes the types of possible runtime code updates. Section 3 gives an overview of STX:LIBJAVA, a Java VM implementation used. In Section 4 we present our solutions and important implementation details. Section 5 discusses future work. In Section 6 we present related work and Section 7 concludes the paper. 2
2.1
There are multiple types of runtime code updates, some of which are already
implemented in the HotSpot VM, or provided by 3rd party tools executing at the
application level, such as JRebel or Javaleon. More complex changes require modification
of the HotSpot VM, as shown by Dynamic Code Evolution VM (DCE VM) project
(Würthinger et al. [
4 http://zeroturnaround.com/software/jrebel/ 5 http://javeleon.com/index.php 6 http://ssw.jku.at/dcevm/ 7 http://www.cs.utexas.edu/ suriya/jvolve/ Feature HotSpot DCE VM JRebel Javaleon JValve
Out of all code updates, update of the method body is the simplest and most often used one. The signature of the method remains the same, only the code of the method is modified, for example after fixing simple bug.
As an example of this change, consider code shown in Listing 1.1. In TicketController, we modify the buyButtonClicked method. The changed method is shown in Listing 1.2.
private TicketView view; private TicketsSeller seller; private TicketValidator validator; public void buyButtonClicked() {
Ticket ticket = view.getTicket(); seller.sellTicket(ticket); 1 public void buyButtonClicked() { 2 Ticket ticket = view.getTicket(); 3 if (validator.isValid(ticket)) { 4 seller.sellTicket(ticket); 5 } else { 6 throw new RuntimeException(); 7 } 8 }
Listing 1.1. Initial code before a method body update
Listing 1.2. Code of the method after the update of the method body 2.3
Binary compatible update does not break the compatibility of the class with any existing code. Following types of updates fall into this category: adding a field8, adding a method, adding a contructor, adding an implemented interface9.
Following on our example in Listing 1.1, consider adding an arbitrary method. Adding this method does not break any existing code. No class depending on the TicketController has to be modified. But, there is an opportunity to modify other classes in the system to use newly added method (in e.g., button click handler). This way the whole system can be improved and evolved at runtime. 2.4
Binary incompatible update breaks compatibility with existing code. The following types of updates fall into this category: removing a field, removing a method, changing a signature of a method, replacing a superclass, removing an implemented interface. Such a situation has to be perceived and handled by the system. The runtime system can rollback the update or apply the update and throw an exception when incompatibility causes a problem.
Imagine we change the signature of the existing method. All dependent classes will keep invoking the class with the old signature, but there is no such method present in the updated class anymore. If the system allows such update, the NoSuchMethodError should be raised. 2.5
Adding and removing a field poses an unique problem. The layout of the object changes. There may be live instances of the updated class. After the update, the instance format expected by the class is different to the instance format on the heap. And simply adding or removing the fields can bring the instance to the unexpected state not attainable by the normal execution. 2.6
Updates to the class and interface hierarchy are the most complex. The methods and fields could be added or removed by updating the hierarchy therefore runtime system must be prepared for such change. From the point of view of the type safety the type correctness of the program could be broken by updating the hierarchy.
Java is 2nd most used language nowadays having more than 17% community share10.
Despite huge popularity, Java still lacks a runtime and development environment
offering dynamic code reloading, interactive and incremental compilation. Also these
features are foundations of high programming productivity of Smalltalk developers (Shan
[
STX:LIBJAVA is an implementation of the Java virtual machine built into the Smalltalk/X environment. In addition to providing the infrastructure to load and execute Java code, it also integrates Java into the Smalltalk development environment including browsers, debugger and other tools.
STX:LIBJAVA aims at providing fully compatible Java VM implementation, which
is also capable of full interoperability with Smalltalk and vice versa. More about the
architecture and interoperability features can be read at Hlopko et al. [
In this section we will briefly outline STX:LIBJAVAs’ internal architecture.
Unlike other projects which integrate Java with other languages, STX:LIBJAVA does not use the original JVM in parallel with the host virtual machine, nor does it translate Java source code or Java bytecode to any other host language. Instead, the Smalltalk/X virtual machine is extended to support multiple bytecode sets and execute Java bytecode directly.
Java runtime classes and methods are implemented as Smalltalk Behavior and Method objects. In particular, Java methods are represented as instances of subclasses of the Smalltalk Method class. However, they refer to the Java bytecode instead of the Smalltalk bytecode. Execution of the Java bytecode is implemented in the virtual machine. In the same way that the Smalltalk bytecode is handled by the VM, the Java bytecode is interpreted and/or dynamically compiled to the machine code (jitted).
The main disadvantage of our approach (as opposed to having a separate original
JVM execute Java bytecodes) is that the whole functionality of the Java virtual machine
has to be reimplemented. This includes an extensive number of native methods, which
indeed involve a lot of engineering work. However, we believe that this solution opens
possibilities to a much tighter integration which would not be possible otherwise.
3.2
Among other information, Java classfile contains a Constant Pool, a pool of constants
and references used within the class (Lindholm and Yellin [
Every class is compiled into separate classfile. In order for this class to be used by the application, the classfile must be loaded and class needs to be linked. Superclass and superinterfaces are (if not already) loaded and linked before the class is linked. Final static fields have to be initialized to their constant value, and the static initializer of the class must be called (possibly setting the values of nonfinal static fields). After that the class is installed into the class registry.
1 public static String getNameAndParams() { 2 return String.format( 3 "%s?useUnicode=true", 4 databaseName); 5 }
Listing 1.3. An example of the method requiring further resolving
References are not only resolved during linking, they may be resolved also later in the runtime. Consider the method at Listing 1.3. The method contains references to the String class and its format method (used for string interpolation), but the method is not called during static initialization of the class. These references are therefore not resolved. They will be resolved, when the first invocation of the getNameAndParams method occurs. This lazy resolving scheme is used by STX:LIBJAVA (and HotSpot VM, DCE VM, Jikes RVM11, JVolve and others).
Now consider the state of the VM as shown in Figure 1. In the top left corner the source code of the currently executed method is shown – the getPaidDate method of the Ticket class. In the top right corner the bytecode of the getPaidDate method is shown. 3 sections follow, first showing the state of the VM before the execution of the GETFIELD instruction, second showing the state after the GETFIELD was executed. The last one will be explained in Section 4.4. In each of sections on the left the constant pool of the Ticket class is shown, in the middle the Java Metadata Area of the VM with Ticket class and its field paidDate are shown. On the right the Java heap is shown, currently containing only one instance of the Ticket class. The instance consists of the header containing various fields needed by the runtime, garbage collection, synchronization etc. These are not relevant to our problem. Instance also contains a class pointer, pointing to the Java Metadata Area, where a runtime Java class representation resides. Finally, instance contains a slot for every field it should have. In our case, the Ticket class only has 3 fields.
Consider the state of the VM from the Part A at Figure 1. ClassRefs and FieldRefs (and the not shown MethodRefs as well) in the constant pool contain a cache field. Initially, the field is empty, but when the reference is resolved for the first time, cache is filled. Next time a reference needs to be resolved, cached value is returned immediately, without the need to lookup the class, method or field, which greatly improves the performance.
When the execution advances, GETFIELD instruction is to be executed. The instance which field is to be loaded is already on the stack, pushed by previous ALOAD_0 instruction. The reference identifying the field is stored in the constant pool at the index 11 http://jikesrvm.org/ public Date getPaidDate() {
return paidDate; } A: Before the execution of the GETFIELD instruction
Java Metadata Area
Java Heap Constant Pool ... 64: 'paidDate' 65: 'cz/.../Ticket' 66: nameAndType { name type } 67: classRef { name: cache: } 68: fieldRef { classRef: 67 nameAndType: 66 cache: nil
Fig. 1. State of the STX:LIBJAVA in different resolving situations 68 (68 is given as an argument to the instruction directly in the bytecode). Situation after the processing of the instruction is shown in Part B at Figure 1. A cache field of the ClassRef at index 67 points to the runtime representation of the Ticket class, cache of the FieldRef points to the runtime representation of the paidDate field of the Ticket class. In our situation, Ticket class has 3 fields, and the offset of the paidDate field is 3. The GETFIELD instruction will retrieve instance data from the heap and will jump to the 3rd slot, pushing the found value to the stack.
Currently, runtime code update support in STX:LIBJAVA operates at the level of a class. Due to the absence of an incremental compiler for Java, the whole class needs to be recompiled on each update. Incremental compiler is able to compile single method, as opposed to whole Java compilation unit, as is the case of the Standard javac compiler – a compiler currently used by STX:LIBJAVA. When update occurs, the difference between the old and new versions of the class is found and the update is handled depending on the type.
In this section we will revisit the types of runtime code updates. For each type we will describe how STX:LIBJAVA supports the update and what were the problems affecting the implementation. 4.1
Updates of the method bodies (described in Section 2.2) are easiest to manage. No existing code is broken and nothing on the heap has to change.
The update could cause changes in the constant pool by e.g., introducing new constants or references in the method body. Therefore constant pool of the new version of the class completely replaces the old constant pool. Also, bytecodes of all methods must be replaced, as the indices into the constant pool may not be valid after the update.
In the case of Figure 1, when getPaidDate method changes, the constant pool of the Ticket class is replaced, and the bytecodes of all its methods are replaced. The change does not affect the TicketController or other classes which depend or use the Ticket class.
There may be running invocations of the updated method. These invocations are not
modified and are left intact. There are attempts to replace the method as it is running
(Kabanov and Vene [
In STX:LIBJAVA, binary compatible updates (described in Section 2.3) are handled similarly to the update of the method body. Whole constant pool and bytecodes of the methods have to be replaced. In addition, new method must be installed into the class.
Another subtle issue may arise when dealing with overloaded methods. By adding a method, an existing method could be overloaded. Java compiler is responsible to choose best-matching method based on the static types of its arguments. There may be classes in the system, which need to be recompiled and updated in order to correctly choose one of overloaded methods.
By default, STX:LIBJAVA ignores these situations. The behavior can be compared to the situation, when the application is compiled against a certain version of a particular library, and then providing different version at runtime. However, dependent classes can be recompiled when explicitly requested. 4.3
The essential problem of this type of update is that it breaks existing code. An application can try to invoke non-existing methods or to store a value to non-existing field. In general, there are 2 solutions: Allowing the update, and throwing an exception, when removed method is accessed. This corresponds to the behavior of the HotSpot VM in the situation mentioned in Section 4.2, when a different version of a library is provided in runtime. When a method existing in compile-time but non-existing in run-time is invoked, the NoSuchMethodError is thrown. Detecting the incompatibility and not allowing the update at all (possibly rolling back other already applied updates). This approach has an advantage that the system is always in compatible state.
In STX:LIBJAVA, these updates are allowed even when they break existing code. When a legacy class tries to invoke a method, which has been removed by the update, an exception is thrown. The exception can be caught and the problem can be fixed by updating the system in runtime, e.g., by implementing missing method or by updating the code calling removed method. 4.4
When a field is added or removed by the update, the instance format changes. In Section 3.2 we showed, that the instance on the heap contains among other unrelevant fields a single slot per declared field. After the layout changing update the fields declared by the class would be different to what currently living instances contain. Additionally, as there are resolved fields stored in the cache field of the FieldRef, the offset stored in resolved field may no longer be valid. Existing classes which have already cached the resolved field may access incorrect or unexisting slot, resulting in heap corruption and in abnormal application termination. Therefore this issue must be addressed by the system. There are 2 solutions – migrating the instances with update or allowing multiple versions of a class to coexist and leave old instances intact.
Updating the class and migrating existing instances is the standard approach taken
by other dynamic code evolution projects for Java (Gregersen and Jørgensen [
Allowing multiple versions of a single class opens the possibility to leave old
instances to live with old class version, and new instances to use new class version. This
is the approach taken by STX:LIBJAVA and by DCE VM (Würthinger et al. [
The migration must happen atomically, as there may be Java threads working with
affected instances. The standard solution is to wait for all threads to reach and wait in
a safe-point (Gregersen and Jørgensen [
Having more than one class version in runtime brings up an issue. As shown in Figure 1, FieldRefs in the constant pool, once resolved, cache the field so when the reference is accessed next time, the resolving phase can be skipped. When there are multiple versions of a single class, the offset of the field can vary depending on the class version of the current instance at runtime.
To illustrate this problem, consider Part C in Figure 1. After the update, which has added contactName field to the Ticket class, there are multiple versions of the class, as shown in Java Metadata Area. Both these versions contain paidDate field, but in the new version, the offset of the field is 4, on contrary to 3 in old version. To solve this problem, classes, which have multiple coexisting versions, are marked as non-cacheable. When a FieldRef is resolved, the marked classes are detected and then the resolved value is not cached. This way the resolving is performed every time.
While solving the problem, this solution is not perfect. As field access is very common operation, STX:LIBJAVA keeps the track of all old class versions in the weak array12. Everytime a reference for non-cacheable class is resolved, the weak array is checked. If the array contains only single item, it means there are no old class versions anymore, the class is marked as cacheable and resolved value can be cached again. Therefore the performance is hindered only for a limited time after the change. The concrete performance measurements have not yet been taken and are part of the future work, as mentioned in Section 5. 12 items in the weak array are free to be collected by the garbage collector 4.5
As described in Section 2.5, two issues must be addressed in order to handle updates to the class and interface hierarchy.
In STX:LIBJAVA, we handle these updates similarly to updates of the instance format (Section 4.4), by allowing both old and new versions of the class to coexist. In this case, the type safety of the existing instances is not broken.
Type safety can be broken, when old instances are migrated by the update, and still
stored in fields of static type not type compatible with new type information. Gupta et al.
[
As the runtime code update support in STX:LIBJAVA is still under development, it has not been tested in the real world yet. We expect and believe, that it would be possible to evolve a Java project from initial version (e.g., first commit in the source code repository) to the latest version without the need to restart the application. Similarly, there is no performance analysis of the runtime code update support in STX:LIBJAVA done yet.
A working incremental compiler for Java would enable us to implement fully interactive environment for Java where it would be possible to start the application before it is completely finished, and to implement missing pieces in the runtime incrementally. A work on such compiler is therefore also part of our future plans.
Currently, all instances are migrated immediately, blocking the execution of all
threads. While this is a solution taken by many (Gregersen and Jørgensen [
JVM Hot Swap is a feature of Java HotSpot VM which enables, albeit limited, dynamic
code updates. HotSpot VM is capable of handling changes to method bodies after
implementation of the first stage of Dmitrievs (Dmitriev [
Dynamic Code Evolution VM (DCE VM) is a modification of the Java HotSpot VM that allows dynamic class redefinition at runtime. It allows for arbitrary code evolution changes including changes to class and interface hierarchy.
DCE VM suffers from an issue, when the dynamic type of variable does no longer match its static type, a problem described at Section 4.5 STX:LIBJAVA does not suffer from this issue and allows for all types of dynamic code changes without breaking the execution. These situations would end up raising a NoSuchMethodError. There is a group of application level tools which operate on unmodified HotSpot VM, while providing runtime code update support for various types of change. These solutions make heavy use of HotSwap feature together with Java class loading. In general, some kind of proxy service is installed and this service dispatches to concrete class versions. By adding a proxy layer these solution bring certain overhead to the normal execution, even when there are no updates applied. Because proxies
JRebel is commercial tool providing support for dynamic changes including
adding/removing methods and fields, but lacks the ability to dynamically change parents
hierarchy (Kabanov and Vene [
Javaleon is another commercial product allowing arbitrary changes to the running Java application, including changes to the parent and interface hierarchies, but updates take effect at the granularity level of components, thus Javaleon is usable only when an application is developed on top of a component system, such as NetBeans Platform or Eclipse Rich Client Platform. In order to operate, Javaleon have to preprocess the whole standard library and all 3rd party libraries used by application.
Javadaptor takes a slightly different approach. Instead of loading classes with new class loader, it performs renaming of the classes, therefore allowing them to be loaded by the existing class loader. Similarly to Javaleon and JRebel, they use bytecode manipulation and dynamic proxying in order to achieve runtime code update.
The big advantage of these tools is that they execute on the standard, unmodified
HotSpot VM, allowing the runtime code updates to be used without the need to update
deployment machines. However, despite large amount of engineering effort put into
these projects (Kabanov and Vene [
Runtime code update as a technique to update a program while it is running has proven to be valuable feature of a runtime system improving development and debugging speed while lowering the costs and downtime of long-running applications. In this paper, we presented runtime class update support in STX:LIBJAVA, a Java VM implementation for Smalltalk/X VM. To our knowledge, STX:LIBJAVA is the only publicly available virtual machine for Java that supports all types of runtime code updates. Runtime code update support enables the STX:LIBJAVA to become the first fully interactive development environment for Java.