just in time compiler termpaper

1. JUST IN TIME COMPILER (JIT)
Term paper submitted
By
To
Department of Computer
Science and Engineering
In partial fulfilment of the Requirement for
the CA of System Software
To
Ms. Mam
(Lecturer)
(December 2013)

2. CONTENTS
 Acknowledgement
 Introduction to JUST IN TIME COMPILERS
 Time space trade off (JIT)
 Functioning of JIT
 Classification of JUST IN TIME COMPILERS
 Conclusion
 References

3. ACKNOWLEDGEMENT
The satisfaction that accompanies the successful completion of any task would be incomplete
without the mention of people whose ceaseless cooperation made it possible, whose constant
guidance and encouragement crown all efforts with success. I am extremely grateful to my
teacher ‘Ms. Chavi Ralhan Mam’ for being a source of inspiration and for her constant support in
the design, implementation and evaluation of this term paper. I am thankful to him for his
constant constructive criticism and valuable suggestions, which benefited me a lot while
developing the term paper on ‘JUST IN TIME COMPILER’. Through this column, it would be
my utmost pleasure to express my warm thanks to him for his encouragement, co-operation and
consent as without which I mightn’t be able to accomplish this term paper.
I would also like to express my thanks to almighty god for his grace and mercy.
Above all, I am extremely thankful to my friends who always remained aside me.

4. INTRODUCTION TO
JUST IN TIME COMPILER
In computing, just-in-time compilation (JIT), also known as dynamic translation, is a method to
improve the runtime performance of computer programs based on byte code (virtual machine
code). Since byte code is interpreted it executes slower than compiled machine code, unless it is
actually compiled to machine code, which could be performed before the execution – making the
program loading slow – or during the execution. In this latter case – which is the basis for JIT
compilation – the program is stored in memory as byte code, but the code segment currently
running is preparatively compiled to physical machine code in order to run faster.
JIT compilers represent a hybrid approach, with translation occurring continuously, as with
interpreters, but with caching of translated code to minimize performance degradation. It also
offers other advantages over statically compiled code at development time, such as handling of
late-bound data types and the ability to enforce security guarantees.
JIT builds upon two earlier ideas in run-time environments: byte code compilation and dynamic
compilation. It converts code at runtime prior to executing it natively, for example byte code into
native machine code.
Several modern runtime environments, such as Microsoft's .NET Framework and most
implementations of Java, rely on JIT compilation for high-speed code execution.
In the Java programming language and environment, a just-in-time (JIT) compiler is a program
that turns Java byte code (a program that contains instructions that must be interpreted) into
instructions that can be sent directly to the processor. After you've written a Java program, the
source language statements are compiled by the Java compiler into byte code rather than into
code that contains instructions that match a particular hardware platform's processor (for
example, an Intel Pentium microprocessor or an IBM System/390 processor). The byte code is
platform-independent code that can be sent to any platform and run on that platform.
In the past, most programs written in any language have had to be recompiled, and sometimes,
rewritten for each computer platform. One of the biggest advantages of Java is that you only

5. have to write and compile a program once. The Java on any platform will interpret the compiled
byte code into instructions understandable by the particular processor. However, the virtual
machine handles one byte code instruction at a time. Using the Java just-in-time compiler (really
a second compiler) at the particular system platform compiles the byte code into the particular
system code (as though the program had been compiled initially on that platform). Once the code
has been (re-)compiled by the JIT compiler, it will usually run more quickly in the computer.
The just-in-time compiler comes with the virtual machine and is used optionally. It compiles the
byte code into platform-specific executable code that is immediately executed. Sun
Microsystems suggests that it's usually faster to select the JIT compiler option, especially if the
method executable is repeatedly reused.
TIME SPACE TRADE OFF (JIT)

6. FUNCTIONING OF JUST IN TIME COMPILERS
In a byte code-compiled system, source code is translated to an intermediate representation
known as byte code. Byte code is not the machine code for any particular computer, and may be
portable among computer architectures. The byte code may then be interpreted by, or run on,
a virtual machine. The JIT compiler reads the byte codes in many sections (or in full, rarely) and
compiles them dynamically into machine language so the program can run faster. Java performs
runtime checks on various sections of the code and this is the reason the entire code is not
compiled at once.[1] This can be done per-file, per-function or even on any arbitrary code
fragment; the code can be compiled when it is about to be executed (hence the name "just-in-
time"), and then cached and reused later without needing to be recompiled.
In contrast, a traditional interpreted virtual machine will simply interpret the bytecode, generally
with much lower performance. Some interpreters even interpret source code, without the step of
first compiling to byte code, with even worse performance. Statically compiled code or native
code is compiled prior to deployment. A dynamic compilation environment is one in which the
compiler can be used during execution. For instance, most Common Lisp systems have
a compile function which can compile new functions created during the run. This provides many
of the advantages of JIT, but the programmer, rather than the runtime, is in control of what parts
of the code are compiled. This can also compile dynamically generated code, which can, in many
scenarios, provide substantial performance advantages over statically compiled code [citation
needed], as well as over most JIT systems.
A common goal of using JIT techniques is to reach or surpass the performance of static
compilation, while maintaining the advantages of byte code interpretation: Much of the "heavy
lifting" of parsing the original source code and performing basic optimization is often handled at
compile time, prior to deployment: compilation from byte code to machine code is much faster
than compiling from source. The deployed byte code is portable, unlike native code. Since the
runtime has control over the compilation, like interpreted byte code, it can run in a secure
sandbox. Compilers from byte code to machine code are easier to write, because the portable
byte code compiler has already done much of the work.

7. JIT code generally offers far better performance than interpreters. In addition, it can in some
cases offer better performance than static compilation, as many optimizations are only feasible at
run-time:
 The compilation can be optimized to the targeted CPU and the operating system model
where the application runs. For example JIT can choose SSE2 vector CPU instructions
when it detects that the CPU supports them. However there is currently no mainstream
JIT that implements this. To obtain this level of optimization specificity with a static
compiler, one must either compile a binary for each intended platform/architecture, or
else include multiple versions of portions of the code within a single binary.
 The system is able to collect statistics about how the program is actually running in the
environment it is in, and it can rearrange and recompile for optimum performance.
However, some static compilers can also take profile information as input.
 The system can do global code optimizations (e.g. in lining of library functions) without
losing the advantages of dynamic linking and without the overheads inherent to static
compilers and linkers. Specifically, when doing global inline substitutions, a static
compilation process may need run-time checks and ensure that a virtual call would occur
if the actual class of the object overrides the inlined method, and boundary condition
checks on array accesses may need to be processed within loops. With just-in-time
compilation in many cases this processing can be moved out of loops, often giving large
increases of speed.
 Although this is possible with statically compiled garbage collected languages, a byte
code system can more easily rearrange executed code for better cache utilization.

8. CLASSIFICATION OF
JUST IN TIME COMPILERS
In the course of surveying JIT work, some common attributes emerged. We propose that JIT
systems can be classified according to three properties:
(1) Invocation:-
A JIT compiler is explicitly invoked if the user must take some action to cause compilation at
runtime. An implicitly invoked JIT compiler is transparent to the user.
(2) Executability:-
JIT systems typically involve two languages: a source language to translate from, and a target
language to translate to (although14 As opposed to the ongoing optimization of Kistler’s [2001]
“continuous optimization,” only compilation occurred concurrently using “continuous
compilation,”and only happened once. these languages can be the same, if the JIT system is only
performing optimization on-the-fly). We call a JITsystem monoexecutable if it can only execute
one of these languages, and polyexecutable if can execute more than one. Polyexecutable JIT
systemshave the luxury of deciding when compiler invocation is warranted, since either program
representation can be used.
(3) Concurrency:-
This property characterizes how the JIT compiler executes, relative to the program itself. If
program execution pauses under its own volition to permit compilation, it is not concurrent; the
JIT compiler in this case may be invoked via subroutine call, message transmission, or transfer
of control to a coroutine. In contrast, a concurrent JIT compiler can operate as the program
executes concurrently: in a separate thread or process, even on a different processor. JIT systems
that function in hard real time may constitute a fourth classifying property, but there seems to be
little research in the area at present; it is unclear if hard real-time constraints pose any unique
problems to JIT systems. Some trends are apparent. For instance, implicitly invoked JIT
compilers are definitely predominant in recent work. Executability varies from system to system,
but this is more an issue of design than an issue of JIT technology. Work on concurrent JIT
compilers is currently only beginning, and will likely increase in importance as processor
technology evolves.

9. CONCLUSION
Here, I conclude my lines of my term paper on the topic ‘JUST IN TIME COMPILER’ with the
extreme satisfaction and contentment. This term paper contains brief definition of Just IN Time
Compiler together with its features and functions.
Added to this, my term paper contains the basic description about Just IN Time
Compiler and its working. It also includes practical implementation of compilation process step
by step. Also I have sincerely included the references from where I have made my term paper.
This term paper is the outcome of my hard and laborious work and contains a complete
knowledge on the path independent line integral.
Here, I end my lines with the hope that my term paper will be equally appreciated and
heartily accepted by all. Also, all my faults and mistakes would be forgiven.

10. REFERENCES :-
 http://searchcio-midmarket.techtarget.com/definition/just-in-time-compiler
 http://en.wikipedia.org/wiki/Just-in-time_compilation
 http://stackoverflow.com/questions/95635/what-does-a-just-in-time-jit-compiler-do
 https://www.google.co.in/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved
=0CCgQFjAA&url=http%3A%2F%2Fweb.csie.cgu.edu.tw%2F~jhchen%2Fcourse%2FP
L2%2FA%2520brief%2520history%2520of%2520just-in-
time.pdf&ei=G_uIUqfPJI6qrAfX4ICQBA&usg=AFQjCNHFGgTcsPOUm4_hZnuF9ggi
d-szmA&bvm=bv.56643336,d.bmk