397,937 Members | 3,828 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 397,937 IT Pros & Developers. It's quick & easy.

JIT Question

Naresh Agarwal
P: n/a
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
Jul 17 '05 #1
Share this Question
Share on Google+
6 Replies


Silvio Bierman
P: n/a

"Naresh Agarwal" <nagarwal@informatica.com> wrote in message
news:2b4b56fb.0401080147.ebe48f1@posting.google.co m...
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


(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
Jul 17 '05 #2

Roedy Green
P: n/a
On Thu, 8 Jan 2004 11:30:53 +0100, "Silvio Bierman"
<sbierman@idfix.nl> wrote or quoted :
The simpler precompilation (


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.
Jul 17 '05 #3

Silvio Bierman
P: n/a

"Roedy Green" <look-at-the-website-for-actual-Roedy@mindprod.com> wrote in
message news:13krvvs4e25ojcvgk6862lntnbppgso7h6@4ax.com...
On Thu, 8 Jan 2004 11:30:53 +0100, "Silvio Bierman"
<sbierman@idfix.nl> wrote or quoted :
The simpler precompilation (


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.


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
Jul 17 '05 #4

Mark Thornton
P: n/a
Silvio Bierman wrote:
"Roedy Green" <look-at-the-website-for-actual-Roedy@mindprod.com> wrote in
message news:13krvvs4e25ojcvgk6862lntnbppgso7h6@4ax.com...
On Thu, 8 Jan 2004 11:30:53 +0100, "Silvio Bierman"
<sbierman@idfix.nl> wrote or quoted :

The simpler precompilation (


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.

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).


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:CompileThreshold option

Mark Thornton

Jul 17 '05 #5

Nick Howes
P: n/a
"Mark Thornton" <mark.p.thornton@ntl-spam-world.com> wrote in message
news:tDPLb.66$YV1.34@newsfep4-winn.server.ntli.net...
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:CompileThreshold option

Mark Thornton


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
Jul 17 '05 #6

Mark Thornton
P: n/a
Nick Howes wrote:
"Mark Thornton" <mark.p.thornton@ntl-spam-world.com> wrote in message
news:tDPLb.66$YV1.34@newsfep4-winn.server.ntli.net...
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:CompileThreshold option

Mark Thornton

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


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

Jul 17 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.