Note: information in this Chapter is not applicable to the Standard Edition of Excelsior JET.
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:
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.
In order to get maximum effect from the startup optimization, follow these recommendations:
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.
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:
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.
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:
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.
The next sections describe how to integrate the startup optimization into 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.
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.
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
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.