[log in to unmask] wrote:
> >[log in to unmask] wrote:
> >> >[log in to unmask] wrote:
> >> >>
> >> >> [someone] wrote:
> >> >>
> >> >> >I don't agree with this since the latest JVMs essentially compile
> >> >> >to native code at runtime anyway.
> >> >>
> >> >> Err - surely that means it is going to take longer if it has to compiler
> >> >> native code at runtime ?
> >> >
> >> >For quick in-and-out programs it would take longer, but once the same
> >> >execution path has been traversed a few times, the cost of the JIT
> >> >compilation has been recovered.
> >> ... until the next time the program is executed.
> Err - Yes... See below.
Perhaps I misunderstood what "until the next time the program is executed"
was referencing: I took it that you were suggesting that due to compilation
being done with every run of the program, the execution time of subsequent
runs would for some reason take longer than that of its first.
> >Take a hypothetical program written in Java that, when wholly run as
> >interpreted byte code, requires 30 CPU minutes to execute.
> >When JIT compiled to native code, it may require only 2 CPU minutes, with
> >JIT compilation requiring only a few seconds of that time.
> >Whether you run it once or a dozen times, each run will require the same
> >amount of execution time.
> The point I was making was that you would have to perform the JIT compilation
> every time you run the program, which is what you are also saying here, unless
> you're suggesting that the JIT compiler also saves the compiled version which,
> as far as I know, is not the case.
Yes, the JIT compilation does have to be performed for every run of the
program. It's just that the time to compile Java Byte Code to host byte
code (object code) is quickly recovered by the time saved by executing
compiled code versus interpreted code for all but trivial programs.
One has to remember that compiling JBC is not like compiling Ada or C++:
The program is guaranteed to be a legal JBC program--meaning no error
diagnosis and recovery required (short of file corruption, in which case
the compiler can just abort), the syntax is simple, the semantics at this
level are simple, the JBC is low-level and assembly language like, so it's
not a great conceptual leap from JBC to object code. Combined, these
aspects permit Java JIT compilers to be very fast.