FORUMS

A Helpful Guide to Music Streaming Services

With the launch of Apple Music, music streaming services have recently gained a lot of … more

An Inside Look at the Redesign of Business Calendar

The much-acclaimed calendar app, Business Calendar, underwent a major design … more

New Android One Device Dead On Arrival

Today, Google announced the second generation of Android One devices, with the new Lava Pixel … more

OnePlus 2 Leaked, Actually Prettier Than Expected

The OnePlus 2 launch event is mere hours away, and we have been treated to clear, … more

Jit compiler

364 posts
Thanks Meter: 0
 
By robin04, Senior Member on 6th April 2010, 12:17 PM
Post Reply Subscribe to Thread Email Thread
This thread has been opened for those who are curious to know how the compiler "just in time".

Functional characteristics in general:

The JIT compiler translates bytecode into native machine code at runtime. This compilation process (also known as dynamic translation) is executed only once, and creates a link between the bytecode and the corresponding compiled code. The purpose of this process is to increase the speed in which to run Java programs.
A JIT compiler is based on two concepts in the recent run-time environments: bytecode compilation and dynamic compilation.
In a system for compiling bytecode as Perl, GNU, Java, etc.. The source code is translated into an intermediate representation known as bytecode. The bytecode is then interpreted or executed in a virtual machine (VM).
In a JIT environment, the first phase is the compilation of bytecodes, which transforms the source code in a portable and optimized intermediate representation, called bytecode. Subsequently, the byte code is installed on the target system. When the code is executed, the compiler execution environment translates into native machine code. The translation into machine code can occur for files or function: the functions can only be completed when they are to be executed, hence the name "just-in-time
The just-in-time compilation allows a good compromise between execution speed and code portability. During the compilation of the bytecode is executed most of the "heavy work", ie all those operations that require a long time to run, as the syntactic and semantic analysis of source code and a first phase of optimization, the compilation from bytecode to native code is much faster.


In particular for android devices:

Here some information on the operation related to android
Essentially, Java is usually translated from source to Java bytecode (an intermediate step between Java itself & processor specific machine code) when the app is compiled. When it is executed, this bytecode has to be interpreted into machine code. What JIT does is cache the results of such interpretation, so that, for example, if a particular section of bytecode is executed multiple times, it will only have to be interpreted that first time. JIT for Java has been around for a good while.
Android uses their own special Java Virtual Machine, which we hear of often - the Dalvik Virtual Machine. This works on similar principles to a typical JVM, but it produces a type of intermediate bytecode that is optimised for execution on devices with limited resources. This code, incidentally, is called a Dalvik Executable, which explains all the .dex sufficies in Android.
As this Dalvik Virtual Machine is relatively new, the further refinement of just in time compilation for it is only now reaching a stage where it's production ready - or at least hopefully will be soon. All pretty exciting as it can boost performance by around 200-300%
Last edited by robin04; 7th April 2010 at 10:35 AM.
 
 
6th April 2010, 02:09 PM |#2  
Senior Member
Thanks Meter: 160
 
More
Quote:
Originally Posted by robin04

I hope to have been sufficiently comprehensive

No, not really. I'm missing the point of this post . Is it a question, is it ment as an answer somewhere else? Did you click on 'post new topic' instead of 'post reply' somewhere?
6th April 2010, 04:31 PM |#3  
robin04's Avatar
OP Senior Member
Flag Padova
Thanks Meter: 0
 
More
Quote:
Originally Posted by dipje

No, not really. I'm missing the point of this post . Is it a question, is it ment as an answer somewhere else? Did you click on 'post new topic' instead of 'post reply' somewhere?

is not difficult to understand.
I just opened a new thread to explain how the JIT.
Who is curious to know how can read the thread.
Anyway thanks for the comment. I'll do some changes to the thread to clarify the reason for its existence.
6th April 2010, 05:21 PM |#4  
kieranc's Avatar
Senior Member
Thanks Meter: 21
 
More
Quote:
Originally Posted by dipje

No, not really. I'm missing the point of this post . Is it a question, is it ment as an answer somewhere else? Did you click on 'post new topic' instead of 'post reply' somewhere?

It's only useful if you realise you don't know what JIT is
I now have a better understanding of how it works, thanks!
6th April 2010, 06:07 PM |#5  
Senior Member
Thanks Meter: 21
 
More
why is it so difficult to bring this to a hero rom? the JiT compiler by google seems to be nearly ready ...
6th April 2010, 06:13 PM |#6  
robin04's Avatar
OP Senior Member
Flag Padova
Thanks Meter: 0
 
More
Need to know to compile the kernel
Last edited by robin04; 7th April 2010 at 10:54 AM.
6th April 2010, 11:26 PM |#7  
Senior Member
Thanks Meter: 4
 
More
Forgive my ignorance, but I thought this was how Android apps always work they come as bytecode and the phone translates them into native code when needed... right?

How else does it work?
7th April 2010, 07:37 AM |#8  
Senior Member
Thanks Meter: 0
 
More
Here's some info on JIT & here's how it pertains to Android

Essentially, Java is usually translated from source to Java bytecode (an intermediate step between Java itself & processor specific machine code) when the app is compiled. When it is executed, this bytecode has to be interpreted into machine code. What JIT does is cache the results of such interpretation, so that, for example, if a particular section of bytecode is executed multiple times, it will only have to be interpreted that first time. JIT for Java has been around for a good while.

Android uses their own special Java Virtual Machine, which we hear of often - the Dalvik Virtual Machine. This works on similar principles to a typical JVM, but it produces a type of intermediate bytecode that is optimised for execution on devices with limited resources. This code, incidentally, is called a Dalvik Executable, which explains all the .dex sufficies in Android.

As this Dalvik Virtual Machine is relatively new, the further refinement of just in time compilation for it is only now reaching a stage where it's production ready - or at least hopefully will be soon. All pretty exciting as it can boost performance by around 200-300%

HTH
Last edited by cauli; 7th April 2010 at 07:44 AM.
7th April 2010, 10:25 AM |#9  
robin04's Avatar
OP Senior Member
Flag Padova
Thanks Meter: 0
 
More
Quote:
Originally Posted by cauli

Here's some info on JIT & here's how it pertains to Android

Essentially, Java is usually translated from source to Java bytecode (an intermediate step between Java itself & processor specific machine code) when the app is compiled. When it is executed, this bytecode has to be interpreted into machine code. What JIT does is cache the results of such interpretation, so that, for example, if a particular section of bytecode is executed multiple times, it will only have to be interpreted that first time. JIT for Java has been around for a good while.

Android uses their own special Java Virtual Machine, which we hear of often - the Dalvik Virtual Machine. This works on similar principles to a typical JVM, but it produces a type of intermediate bytecode that is optimised for execution on devices with limited resources. This code, incidentally, is called a Dalvik Executable, which explains all the .dex sufficies in Android.

As this Dalvik Virtual Machine is relatively new, the further refinement of just in time compilation for it is only now reaching a stage where it's production ready - or at least hopefully will be soon. All pretty exciting as it can boost performance by around 200-300%

HTH

Thanks for the deepening. Add this post to the first
7th April 2010, 10:39 AM |#10  
Senior Member
Flag Ealing
Thanks Meter: 353
 
More
Quote:
Originally Posted by FunkTrooper

Forgive my ignorance, but I thought this was how Android apps always work they come as bytecode and the phone translates them into native code when needed... right?

How else does it work?

In a typical Java environment, without JIT, the application is always interpreted. This makes the applications exceptionally portable, since the underlying architecture (CPU instruction set etc) is largely immaterial.

In a JIT environment, some or all of those bytecodes (as JIT usually works by method) are compiled directly down to native code as the application is run (hence Just-In-Time). Some or all of the application then effectively becomes a native application targeted at a specific architecture rather than an fully interpreted application.

Simplistically, the net result is that a JIT-compiled app is usually slower to start, but faster to run.

See here for some details of Android JIT compilers.

On a related note, not all Android applications are fully interpreted java anyway. If an application uses the NDK, portions of it may be written as native code (see here).

Regards,

Dave
7th April 2010, 02:31 PM |#11  
Senior Member
Thanks Meter: 0
 
More
Interesting thread, one thing I don't know is if the native code produced by JIT is just cached or stored? Ie if its cached, starting an application will take a while the first time, then really quick the second time until that app is taken out of the cache

Or is it that the JIT native code replaces the java on that device, so once run, its always quicker even if the phone is rebooted etc?

Read More
Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes