JIT Question

[Naresh Agarwal]

Hi

How does JIT compilers work? Does they first compile the *entire*
bytecode into machine code and then starts execution? Or they first
compile a method, execute that and then compile another method and
execute that and so on. Why it is called as "Just In Time"?

Interpreters also need to compile to bytecode before execution. Thus
whether a java bytecode is executed by interpreter or JIT compiler,
the compilation will be required in the both the cases. Then why does
JIT compilers are slower then interpreters in certain cases?


Also does the current JVMs (JDK 1.3 and 1.4) supports JIT? Which JVM
versions supports JIT?

Does HotSpot VM supports JIT?

thanks,
Naresh

[Silvio Bierman]

Re: JIT Question


"Naresh Agarwal" <nagarwal@infor matica.com> wrote in message
news:2b4b56fb.0 401080147.ebe48 f1@posting.goog le.com...[color=blue]
> Hi
>
> How does JIT compilers work? Does they first compile the *entire*
> bytecode into machine code and then starts execution? Or they first
> compile a method, execute that and then compile another method and
> execute that and so on. Why it is called as "Just In Time"?
>
> Interpreters also need to compile to bytecode before execution. Thus
> whether a java bytecode is executed by interpreter or JIT compiler,
> the compilation will be required in the both the cases. Then why does
> JIT compilers are slower then interpreters in certain cases?
>
>
> Also does the current JVMs (JDK 1.3 and 1.4) supports JIT? Which JVM
> versions supports JIT?
>
> Does HotSpot VM supports JIT?
>
> thanks,
> Naresh[/color]

(response cross-posted to c.l.j.a)

Interpreters must parse sourcecode/bytecode but do not neccessarily
"compile" it. Even if they do the compilation outcome can be some abstract
instruction set not matching any processor hardware (that would be called
something like bytecode).

The Sun JIT starts executing bytecodes directly and builds a statistical
analysis of which code gets executed how often. As soon as it decides some
code is up for JIT-ting it is compiled to native machine code to be executed
faster from that point on.

Personally I would have preferred precompilation of a complete class file as
soon as it is loaded. That is what I call JIT. The way it works now in my
opinion should not be called JIT but JTL instead (Just Too Late, obviously).

People at Sun are so charmed by the concept they came up with once that they
blindly cling to it. The simpler precompilation (backup up by a smart JVM
level caching scheme would be an enormous performance boost. They insist
that more efficient compilation/optimization is possible when runtime
characteristics are know (as they are during JTL compilation) but that is
bullshit. This delivers a marginal advantage over preanalysis that can never
make up for the time lost with a) interpreting code initially b) time spent
during compiling at runtime c) time lost because of not being able to cache.
The memory-use argument is silly except for j2me.

Understand me correctly: I love Java and think it is one of the best
software development of the past ten years. I agree that static compilation
is not an option but I think the .NET precompilation scheme is much simpler
and more efficient. The Java JIT scheme is only better in mostly academic
perspectives and unfortunately gives us a performance disadvantage in
comparison with .NET.

Now I mentioned .NET: I have been a long time Win32 developer (C++ from
about '92) and gradually shifted to Java about four years ago. Did not look
back until some .NET projects came up that needed resqueing. Looked at .NET
(Winforms, ADO.NET and ASP.NET) and was absolutely disgusted. .NET is gross.

Just my ?0.02,

Regards,

Silvio Bierman

[Roedy Green]

Re: JIT Question

On Thu, 8 Jan 2004 11:30:53 +0100, "Silvio Bierman"
<sbierman@idfix .nl> wrote or quoted :
[color=blue]
>The simpler precompilation ([/color]

If you want that use a native compiler. See

http://mindprod.com/jgloss/nativecompiler.html

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

[Silvio Bierman]

Re: JIT Question


"Roedy Green" <look-at-the-website-for-actual-Roedy@mindprod. com> wrote in
message news:13krvvs4e2 5ojcvgk6862lntn bppgso7h6@4ax.c om...[color=blue]
> On Thu, 8 Jan 2004 11:30:53 +0100, "Silvio Bierman"
> <sbierman@idfix .nl> wrote or quoted :
>[color=green]
> >The simpler precompilation ([/color]
>
> If you want that use a native compiler. See
> http://mindprod.com/jgloss/nativecompiler.html
>
> --
> Canadian Mind Products, Roedy Green.
> Coaching, problem solving, economical contract programming.
> See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.[/color]

No, I dont want a native compiler. I want slightly different behaviour from
the Sun JRE. Mark suggested there are options for precompilation but that is
not true for the Sun JREs, maybe for IBMs JRE but that is not up to date
enough (had serious problem with using that with JIT enabled anyway).

JIT compilation is absolutely fine. I would just like to be able to ensure
no code ever is interpreted but always compiled-on-load, even as
fine-grained as the method level is OK with me. Backup up by a good caching
scheme this is more than efficient enough to not want native compilers
producing platform binaries. Look at .NET, this is about the only thing they
got right (slightly exaggerating here, off course).

Regards,

Silvio Bierman

[Mark Thornton]

Re: JIT Question

Silvio Bierman wrote:[color=blue]
> "Roedy Green" <look-at-the-website-for-actual-Roedy@mindprod. com> wrote in
> message news:13krvvs4e2 5ojcvgk6862lntn bppgso7h6@4ax.c om...
>[color=green]
>>On Thu, 8 Jan 2004 11:30:53 +0100, "Silvio Bierman"
>><sbierman@idf ix.nl> wrote or quoted :
>>
>>[color=darkred]
>>>The simpler precompilation ([/color]
>>
>>If you want that use a native compiler. See
>>http://mindprod.com/jgloss/nativecompiler.html
>>
>>--
>>Canadian Mind Products, Roedy Green.
>>Coaching, problem solving, economical contract programming.
>>See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.[/color]
>
>
> No, I dont want a native compiler. I want slightly different behaviour from
> the Sun JRE. Mark suggested there are options for precompilation but that is
> not true for the Sun JREs, maybe for IBMs JRE but that is not up to date
> enough (had serious problem with using that with JIT enabled anyway).[/color]

I believe the options do exist on the Sun JRE, the problem is finding
documentation.

http://java.sun.com/docs/hotspot/VMOptions.html

Try the -XX:CompileThres hold option

Mark Thornton

[Nick Howes]

Re: JIT Question

"Mark Thornton" <mark.p.thornto n@ntl-spam-world.com> wrote in message
news:tDPLb.66$Y V1.34@newsfep4-winn.server.ntl i.net...[color=blue]
> I believe the options do exist on the Sun JRE, the problem is finding
> documentation.
> http://java.sun.com/docs/hotspot/VMOptions.html
>
> Try the -XX:CompileThres hold option
>
> Mark Thornton
>[/color]

I may have misread the description for the -XBatch command switch but it
might precompile fully. maybe.

from

http://java.sun.com/j2se/1.4.1/docs/tooldocs/linux/java.html

[Mark Thornton]

Re: JIT Question

Nick Howes wrote:[color=blue]
> "Mark Thornton" <mark.p.thornto n@ntl-spam-world.com> wrote in message
> news:tDPLb.66$Y V1.34@newsfep4-winn.server.ntl i.net...
>[color=green]
>>I believe the options do exist on the Sun JRE, the problem is finding
>>documentation .
>>http://java.sun.com/docs/hotspot/VMOptions.html
>>
>>Try the -XX:CompileThres hold option
>>
>>Mark Thornton
>>[/color]
>
>
> I may have misread the description for the -XBatch command switch but it
> might precompile fully. maybe.
>
> from
> http://java.sun.com/j2se/1.4.1/docs/...inux/java.html
>
>[/color]

I interpret that as meaning that it still uses the interpreter to start
with, but when it decides a method is worth compiling the compilation is
done directly. The normal mode means that the application continues
using the interpreted (or previous compiled code) until the new
compilation is ready.
In any case if you don't like how the Sun JVM does it, you can always
try an alternative JVM such as those from IBM.

Mark Thornton