0 Replies Latest reply: Dec 6, 2008 9:10 PM by 843829 RSS

    Just-in-time compilation affecting time-sensitive application?

      Hi. I have a SWING application which allows a user to select and run a 'job', where the calculation of a job consists of submitting a number of tasks to a method which in turn is highly recursive. The recursive method is restrained by a timer; after 1000 milliseconds (say) of real time the recursive method will return with any results it was able to calculate in that time interval for the task to its caller; after which the program will iterate to setting up another task and handing that off in turn to the recursive method anew.

      I've found that, when a job is run for the first time after program startup, the recursive method will take about 800ms longer to arrive at its normal solution for its first task. But after the job has been run once the user can re-run the exact same job and the recursive method will execute in the expected time period.

      In fact the timing for one configuration of a job is like this for the method:

      First run: 848ms
      Second run: 401ms
      Third run: 315ms
      Fourth run: 225ms

      After which it usually runs around the 220ms mark.

      I'm running java build 1.6.0_10-b33 under Linux 2.6.26 on an Intel Core-2 Quad Q6600.

      Using strace I worked out what classes were being loaded from disk by the recursive method and pre-loaded them, which shaved about 200ms off the original timing before arriving at the figures I've listed above. I can't think of anything else I can do to remove any other once-only delays.

      The problem of the longer-than-normal first run is critical to the application because, for some jobs, the recursive method will fail to calculate an optimal result if it takes longer to run its first task, being curtailed prematurely upon receiving its 1000ms real-time timeout.

      I'm thinking that the above behaviour - slow execution at first, then speeding up - might be a classic symptom of the Java JIT compiler. The recursive method uses a few lists and other API classes so I imagine both the method itself and those methods it uses (heavily) would be gradually compiled as it is progressively used?

      Is there any way I can 'pre-compile' a specific method or class of an application?

      I've used '-Xcomp' but not only does that option drastically increase the startup time of the application - which I expected and was prepared to accept - it also slows down the recursive method itself! -

      First run: 1300ms
      Second: 474ms
      Third: 317ms

      I suppose as a last-ditch attempt to fix this I could make a kludge and hardwire an embedded artifical 'job' to run as part of the application startup, but that's pretty inelegant.

      I'm only a 'user level' java programmer and haven't played at all with internals or profiling. If my problem is a common one I apologise for taking your time and would appreciate advice to help me bootstrap into learning what I need to know. Thanks!