JavaParty

Multi-Application Enhancement

Since JavaParty 1.9.4

Introduction

Up to now it was only possible to start exactly one application in a JavaParty environment. The multi-application enhancement allows running multiple JavaParty applications concurrently in the same environment. So JavaParty applications can be started successively without starting the runtime system for each program separately. Individual applications are handled as before and the user may shut down the JavaParty environment anytime he wants.

On certain conditions, new virtual machines and thus computing power can be dynamically added to the runtime system. In either case the classes loaded by a JVM are shared by all concurrent applications. Therefore another goal is to deal with dynamically modified classes on demand. In doing so programs that run consecutively in the same environment can address different classes under the same name.

Starting multiple JavaParty applications

Recall that the JavaParty runtime system is started by calling javaparty rm [option]*. Then an arbitrary number of virtual machines can be added to the runtime environment with the command javaparty vm [option]*. As soon as the environment is set up the user can start a JavaParty application with the command javaparty exec <program> [parameter]*. Depending on the operating system it is possible to run programs in the background and start additional processes. The multi-application enhancement allows additional JavaParty applications to be started concurrently by using the command javaparty exec.

If the user decides to start multiple applications concurrently in the JavaParty environment, these applications share the loaded classes. The advantage is that for programs which use the same classes, the expenses for reading the class files only incur once. Note that different applications cannot use different versions of the same class.

Static fields are initialized at load time and are accessed by all instances in common. Since static fields keep their values even when the application is terminated, they can influence other programs that run in the same JVM and use the corresponding class. The classes generated by the JavaParty compiler contain no static fields and thus no additional problems occur.

Behaviour of the runtime environment

If an application should operate at a higher performance, additional VMs may be added to the runtime environment. A precondition is that currently no application is executed in the JavaParty environment and the caches were flushed, as described below. When the user starts a new program in the runtime environment, a Semaphore guarantees that no virtual machines may register with the runtime system. After the start and during the execution of the program, the runtime system prevents further registrations of VMs.

By default all caches of the runtime system are flushed as soon as an application is started in an empty JavaParty environment. Whether the environment has been used before or not is negligible because the caches must be initialized for the first program that runs in the environment.

In order to use the Java’s capabilities to cache classes in the memory, the user can pass the parameter -noreset when starting the runtime manager. It causes the caches to be conserved for future applications that run in the same environment even after the termination of all programs. Currently the choice to reset the caches is only available during the creation of the runtime manager. If the user has to engage with the runtime system, he can reset the environment and thus the caches by using the parameter -reset while stating an application. The global setting in the runtime manager remains unchanged.