Bring Back LTE on the Google Nexus 4 Running Lollipop

One of the predecessors of the latest, largest, and greatest Gooogle Nexus 6(theGoogle … more

Google Maps, My Maps, YouTube, Androidify, Slides, Music Updated–Here’s What’s New

In the last few weeks, Google has been … more

SuperSU BETA: Root Android Lollipop on Stock Kernel

Up until now, if you wanted to get root on Android 5.0, you needed to flash a modified … more

Android App Review: Get Amaze with Material Design – XDA TV

Material Design is all the buzz in the Android world right now. Android 5.0 … more

Welcome to XDA

Search to go directly to your device's forum

Register an account

Unlock full posting privileges

Ask a question

No registration required
Post Reply

Jit compiler

OP robin04

6th April 2010, 01:17 PM   |  #1  
robin04's Avatar
OP Senior Member
Flag Padova
Thanks Meter: 0
 
364 posts
Join Date:Joined: Jan 2010
More
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 11:35 AM.
6th April 2010, 03:09 PM   |  #2  
Senior Member
Thanks Meter: 151
 
725 posts
Join Date:Joined: Oct 2006
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, 05:31 PM   |  #3  
robin04's Avatar
OP Senior Member
Flag Padova
Thanks Meter: 0
 
364 posts
Join Date:Joined: Jan 2010
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, 06:21 PM   |  #4  
kieranc's Avatar
Senior Member
Thanks Meter: 21
 
145 posts
Join Date:Joined: Feb 2008
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, 07:07 PM   |  #5  
Senior Member
Thanks Meter: 17
 
151 posts
Join Date:Joined: Jan 2010
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, 07:13 PM   |  #6  
robin04's Avatar
OP Senior Member
Flag Padova
Thanks Meter: 0
 
364 posts
Join Date:Joined: Jan 2010
More
Need to know to compile the kernel
Last edited by robin04; 7th April 2010 at 11:54 AM.
7th April 2010, 12:26 AM   |  #7  
Senior Member
Thanks Meter: 4
 
112 posts
Join Date:Joined: Nov 2009
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, 08:37 AM   |  #8  
Senior Member
Thanks Meter: 0
 
320 posts
Join Date:Joined: Mar 2010
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 08:44 AM.
7th April 2010, 11:25 AM   |  #9  
robin04's Avatar
OP Senior Member
Flag Padova
Thanks Meter: 0
 
364 posts
Join Date:Joined: Jan 2010
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, 11:39 AM   |  #10  
Senior Member
Flag Ealing
Thanks Meter: 310
 
3,858 posts
Join Date:Joined: Mar 2008
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

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

Advanced Search
Display Modes