Super Prev Next

Startup time optimization

Note: information in this Chapter is not applicable to the Standard Edition of Excelsior JET.

Super Prev Next


The memory paging technique, used by contemporary operating systems, creates a considerable overhead on application startup time, because:

Typically, this appears in the following scenario: on the first launch after system reboot (cold start), an application starts much longer than on any subsequent launch (warm start) when its files are cached in memory by the operating system.

Therefore, it is desirable to optimize application executables so as to minimize the number of pages to be loaded on startup and to ensure that the pages are accessed in an order close to sequential. This can be done with the Startup Optimization Toolkit included with Excelsior JET, which can reduce:

Super Prev Next

Startup Optimization Toolkit

The Startup Optimization Toolkit comprises:

Both tools are profile-guided, that is, the application should be run in a profiling mode to collect the run-time information which is then used for the optimization. The good news are that you have to do nothing special to enable the startup optimization because these tools are integrated into the JET Control Panel.

Super Prev Next

Application considerations

In order to get maximum effect from the startup optimization, follow these recommendations:

  1. Use both the Startup Optimizer and the Startup Accelerator as they complement each other.
  2. For small- and medium-size applications /Say, applications whose classpath includes 15,000 classes at most./ , enable the Global Optimizer to take the standard Java SE packages used by the application in the optimization scope.
  3. If your software product contains several applications sharing common Java libraries, build the applications together into a multi-app executable (see Multi-app executables).

Known limitation: If you create a multi-component application (see Multi-component applications), that is, compile the application’s jar files into the executable and dynamic libraries, the effect of using the Startup Optimization Toolkit may be insignificant because the overheads of loading the libraries are not optimized.

Super Prev Next

Enabling startup optimizations

Super Prev Next

How to turn the Startup Optimizer on

Just run your application once on the page Test Run of the JET Control Panel before compilation and then build the executable as usual.

Here is what happens behind the scenes when you do that:

  1. During the Test Run, a startup profile of the application is collected and saved into a file. The file is created in the application’s working directory and has the .startup extension
  2. This file is automatically added to the project
  3. The compiler reads the profile data from that file and performs the necessary optimizations

Though it requires you to run your application to gather the profile data, you do not need to repeat this step each time you modify your application. In most cases, the profile created for the Startup Optimizer is quite stable. You may wish to recollect it before making the final build for pre-release QA or integrate the profiling into the established automated build as described in section Startup Optimizer in automated builds.

Super Prev Next

How to turn the Startup Accelerator on

In the JET Control Panel, the Startup Accelerator is enabled by default. Immediately after build, the Control Panel automatically runs the application just compiled and collects the profile data. You may only need to configure the default settings such as profiling timeout as described in section Configuring Startup Accelerator.

Under the covers, it works as follows:

  1. The compiled application is automatically run for profiling
  2. Profile data is collected and the application is automatically terminated on the specified timeout
  3. The collected profile is then hard-wired into the application executable
  4. Upon application startup, the JET Runtime uses the profile data to reduce the startup time

Note: Any recompilation of the application not followed by the profiling run of the resulting executable disables the optimization. To address this problem, the Startup Accelerator is also integrated with the command line JET compiler which is able to automatically run the executable in the profiling mode just after building a project. This and other options of integration of the Startup Accelerator in automated builds are covered in details in Startup Accelerator in automated builds.

Super Prev Next

Automated builds

The next sections describe how to integrate the startup optimization into automated builds.

Super Prev Next

Startup Optimizer in automated builds

You may automate the collection of startup profile to include this step in your established build process. For that, you run your Java application with the xjava utility specifying the name of the resulting profile file in the jet.jit.profile.startup property on command line, for example

xjava -Djet.jit.profile.startup=Foo.startup -jar Foo.jar

Upon application exit, the collected information will be written into the specified file created in the application’s working directory. In the example above, the information will be saved to Foo.startup.

Note: If a profile file with the same name already exists, it will not be overwritten, but new information will be added to it.

The profile filename is specified in the project via the STARTUPPROFILE equation (see STARTUPPROFILE - start up profile file). Provided you performed a Test Run at least once, the JET Control Panel adds this equation to the project. When automating the collection of the startup profile, make sure that the profile filename written in the project matches what you have specified on the xjava command line.

Super Prev Next

Startup Accelerator in automated builds

If the application can be run on the same machine where it is compiled, the integration of the Startup Accelerator into the build is very simple:

As a result, the JET compiler will automatically run the application in the profiling mode right after building the project and hard-wire the profile data into the resulting executable. Note that the duration of the profiling session is defined by the timeout you specify as follows:

Make sure that the timeout is long enough to capture the application startup.

Super Prev Next

XSTARTUP utility

If, for some reasons, you want to profile the application independently of its compilation, you use the xstartup utility specifying the application executable, the working directory and the profiling timeout. For example, this command

    xstartup --work-dir=foo bar/MyApp.exe

launches bar/MyApp.exe from directory foo, profiles the application startup and hard-wires the collected data into executable MyApp.

Note: You may run the xstartup utility after deploying the application to another machine. However, if you use the Excelsior Installer to power the installation package created with JetPackII, there is no intermediate step when xstartup could work. As the similar problem arises when using license managers, which also need to modify the compiled executable, you may use the packaging technique described in section Installations protected by license managers.


    xstartup [ options ] executable-name application-arguments


Command-line options of xstartup.

Pathname of the executable file to be profiled. The collected data will be automatically hard-wired into it.

Command-line arguments of the application executable, if any.


-t n

Sets the profiling timeout to n seconds. The application will be automatically terminated on this timeout. The default value is 20 seconds.

Specifies the working directory for the running application. This switch is mandatory and must be set for any xstartup command.

In most cases, it is enough to set “.” as directory-pathname. But if the behavior of your application depends on the directory from which it is launched, specify the directory’s pathname.