FastPak for Java Performance Benefits

FastPak for Java can, in many cases, improve performance for both Java applications and native applications running inside and outside the FastPak environment.

The Java virtual machine (JVM) used to launch Java applications is a resource hog. Every time an application is launched via a command line, by double clicking on a jar file, or by using another application launcher such as Web Start, a new JVM is also started corresponding to the application. If you want to run five applications, you end up starting five JVMs.

Because each JVM acts essentially as a sub-operating system within the operating system, each JVM instance associated with each application being launched requires another re-allocation of, and access to the operating system's video, network, memory, threads, processes, and disk resources (to name a few). Todays multi-tasking operating systems must add all the handles to these resources into its queues, and then time slice and swap out the memory as each task becomes active. The net result is an unneccesary load on the operating system, which can manifest itself with overall system degredation for not only the Java applications being executed, but native applications and the operating system itself. Many users have complained that when too many Java applications are launched on a system simultaneously, response, such as keyboard I/O or the launching of other applications becomes delayed.

FastPak for Java can help alleviate this problem by running multiple Java applications under a single JVM. Under FastPak, each Java application shares the operating system's resources, and the allocation and scheduled use of those resources is handled within the confines of the FastPak kernel and its hosting JVM. With this in mind, FastPak users should experience the following benefits:

• Far less memory consumption

• Far fewer threads and processes are allocated

• Less disk activity because of reduced swapping

• Less application interference because of the overall reduction in the items mentioned above

FastPak for Java does have its limitations. Potential customers should download and review the documentation before assuming, inacurately, that FastPak can solve problems that may exist within an application itself. The following list provides some of the more prevalent problems that may exist or become apparent when an application is run under FastPak:

• An Application Uses Considerable System Resources By Itself: If an application is using up a considerable amount of system resources all by itself (for example, it tries to allocate 400MB of memory on a system with 512MB of memory installed), FastPak cannot alleviate or even help with such extreme resource consumption. The only reason to use FastPak in this case would be to launch the application locally or remotely and use the FastPak Controller thread for monitoring and control.

• GUI Programs Block the Event Dispatching Thread (EDT): Realistically, this is a bug and a general "no-no" but some people do it anyway. If an application blocks the EDT, on FastPak this blocking will also block other applications that need to make use of the thread. This is typically limited to GUI programs. Users can, however, run such programs outside of FastPak since FastPak doesn't mandate it be used for all applictions.

• The Program is Inherently Buggy and Throws Exceptions: FastPak won't fix this. Depending on the nature of the errors, it may even cause FastPak to crash. Don't use buggy programs with FastPak if it's running multiple Java applications.

• You're Running One and Only One Application, and There is No Need for the Remote Access, Launching, and Monitoring Provided by the FastPak Controller Thread : This is a case where FastPak will generally provide you with no benefits at all. There is no point in using FastPak if this is your working environment.

If you're interested in seeing how well FastPak performs during some of our own tests, click on the following link:

Overview of FastPak Performance