₦airaland Forum

dhtml18:
Corecta! and JIT compilers stands for Just-In-time Compilers.
And to quote someone on stackoverflow:

A JIT compiler runs after the program has started and compiles the code (usually bytecode or some kind of VM instructions) on the fly (or just-in-time, as it's called) into a form that's usually faster, typically the host CPU's native instruction set. A JIT has access to dynamic runtime information whereas a standard compiler doesn't and can make better optimizations like inlining functions that are used frequently.

This is in contrast to a traditional compiler that compiles all the code to machine language before the program is first run.

To paraphrase, conventional compilers build the whole program as an EXE file BEFORE the first time you run it. For newer style programs, an assembly is generated with pseudocode (p-code). Only AFTER you execute the program on the OS (e.g., by double-clicking on its icon) will the (JIT) compiler kick in and generate machine code (m-code) that the Intel-based processor or whatever will understand.
Source: http://stackoverflow.com/questions/95635/what-does-a-just-in-time-jit-compiler-do

Nice

jibolash:
The way the OP phrased his post has made many people who haven't toyed with Javascript on the server side before to misunderstand him.

Using Javascript on the server side is done with NodeJS as some people have already mentioned. Basically the syntax is still Javascript but the environment is quite different. @Nickzom Are you using a NodeJS framework or is it just pure node?

I have built a couple of full stack Javascript apps using the MEAN (MongoDB, ExpressJS, AngularJS, NodeJS) stack. You can check them out here http://andela-asogbein.github.io/andebooksclient and here http://andela-ssunday.github.io/tangong/.

Both projects are on my github. My username is andela-asogbein

THANK YOU JOOOR!!
Implementing pure node but having a little interest on nodeJS these days.

dhtml18:
Corecta! and JIT compilers stands for Just-In-time Compilers.
And to quote someone on stackoverflow:

A JIT compiler runs after the program has started and compiles the code (usually bytecode or some kind of VM instructions) on the fly (or just-in-time, as it's called) into a form that's usually faster, typically the host CPU's native instruction set. A JIT has access to dynamic runtime information whereas a standard compiler doesn't and can make better optimizations like inlining functions that are used frequently.

This is in contrast to a traditional compiler that compiles all the code to machine language before the program is first run.

To paraphrase, conventional compilers build the whole program as an EXE file BEFORE the first time you run it. For newer style programs, an assembly is generated with pseudocode (p-code). Only AFTER you execute the program on the OS (e.g., by double-clicking on its icon) will the (JIT) compiler kick in and generate machine code (m-code) that the Intel-based processor or whatever will understand.
Source: http://stackoverflow.com/questions/95635/what-does-a-just-in-time-jit-compiler-do

Thank you 4 that point

You are welcome people

micodon:
1. Never did I say that that JIT compilers interprets Machine code. don't misquote me. The Interpretation is done on your Script, your source code. The JavaScript JIT compiler translates your script into bytecode which is just a map of tokens (created by the lexical analyzer) to their equivalent Javascript's bytecode. At the end of The JavaScript's Jit compiler's process, It's bytecode's interpreter transpiles, or translates or compiles it to Native Code for the machine to understand. That's the point. At one point in time, your script has to be presented to your machine in its native code for it to run.

2. Java and C# are compiled languages. THEY ARE PRECOMPILED BY THE PROGRAMMER BROS. Take note of that point. Java to JavaByte code, which is understood by the JVM. C# to MSIL.

3. JIT compilers are just compilers. The Language runtime may have lexical analyzer, parser, interpreter, and the compiler. They work together. Much of your problems come from the fact that you think that interpreters are compilers. they are not.

4. I said languages are BROADLY CLASSIFIED INTO TWO. Understand that language.

I can get u. Is like this is becoming more interesting and seriously I am really gaining. Thumbs up Micodon, dhtml18

I will like to react further on the issue of Compiler and Interpreter. Also Categories of Languages. I think where the problem still lies is the machine code issue/storage issue and will like to dwell much on them.

To me I can say We have the following Structure;

-Interpreter

-JIT/AOT Compiler

-Conventional Compiler

INTERPRETER
As for Interpreter it interprets/parses/converts the source code/intermediate code to machine code without storing it. That is why each time the code is run, it converts it again to machine code. The machine code are never stored anywhere on the system.


"I want to add this to the meaning of Compilation. Compilation significantly differs from interpretation or converting in the sense that when compilation is done machine codes are stored in a file or in memory. When interpretation is done machine codes are never stored. Interpreters just read the code line by line and parse it converting it to machine code but never store it.


JIT COMPILER
JIT Compiler compiles source code or intermediate code (like bytecode, MSIL) to machine code and store it in memory. That is it "cache" it. I believe we understand "Cache". In Computer Storage Technology, one of the least rudimentary computer storage is Cache. JIT does not only do compilation but also interpret the source code/intermediate code at runtime at first run to at least third run of the code.
In operation, JIT Compiler interprets the source code/intermediate code and at thesame time compiles the code. After two or three runs, JIT Compilers no longer interprets, it just straight away run the code in the machine code already cached.

Conventional Compilers
These Compilers compile all the source code/intermediate code and store them in a file on the system.
For example:
For C Language:
When you code in C you save as .c extension like app.c
When you give this file "app.c" to a C - Compiler it first create a file called app.o
Then it begins to read your codes and compiles them storing them into app.o
Note: Your .o extension means Object File.
Now that the compiler has stored the machine code (like x86 cpu code) into app.o then it can then run the code directly from app.o
About .exe files, a "linker" is used to connect the object file containing the machine code (app.o) with the .exe file like app.exe for execution.

For Java Language:
When you code in Java, you save as .java extension like app.java
When Java Compiler like "javac" the most used handles the app.java, it first create a file of .class extension like app.class
Then it reads the code and compiles it to byte-code by storing the byte-code inside app.class file.
The work of "javac" in Java Development Kit (JDK) ends as soon as it compiles Java Source Code to byte-code and stores them inside app.class.
Then Java Virtual Machine (JVM) in Java Runtime Environment (JRE) takes it from the point at which the Compiler stop and run the byte-code by interpreting/parsing/converting it to machine code just as explained above under Interpreters.
Therefore, app.class containing byte-code is run directly by JVM Interpreter.
Simply put, In Java Programming two things happen.
1. Java Source Code is compiled to byte-code
2. Byte-code is interpreted at runtime.

@ Micodon this is the area I was expecting you to hit when I asked you under which category will you classify Java and C#, because the two of them compiles to an intermediate code by storing them in a file system and also interprets the intermediate language. So when one talks about compiled languages the duo can fit in. When you talk about interpreted languages the duo too fit in.

The cunning way of JIT compilers comes in here as it also compiles and interprets. And the difference is clear that JIT stores in memory while conventional compilers stores inside a file system. Also, JIT storage technique is not done once like conventional complilers. JIT stores procedurally by getting the functions that is run and compile them to machine code. Just as Micodon said which is the basic principle behind JIT compiler, 'it is used to optimize the performance of interpreters, so that when the code is run more than once it can optimize it for the subsequent runs.
"Anyway at your discretion"

To be on the safer side, I believe we can say;
Compiled languages, Interpreted languages and Hybrid Languages (Compiled and Interpreted)

Finally, just as I have said any language can be compiled or interpreted. Anybody can work on JavaScript Programming to do compilation by storing in a file system. One can develop a compiler that will create a file to store machine code and run the JavaScript code directly from the file containing the cpu code. But without that for now our JIT/AOT Compilers have helped solved the issue of slow - slow.

Observation: JIT Compiler does not compile only byte-code. Like V8 Engine, its JIT Compiler compiles directly to machine code. JVM JITs, Rhino etc are the once I know that do that.

Thanks.

Olumyco:
I can get u. Is like this is becoming more interesting and seriously I am really gaining. Thumbs up Micodon, dhtml18

I will like to react further on the issue of Compiler and Interpreter. Also Categories of Languages. I think where the problem still lies is the machine code issue/storage issue and will like to dwell much on them.

To me I can say We have the following Structure;

-Interpreter

-JIT/AOT Compiler

-Conventional Compiler

INTERPRETER
As for Interpreter it interprets/parses/converts the source code/intermediate code to machine code without storing it. That is why each time the code is run, it converts it again to machine code. The machine code are never stored anywhere on the system.


"I want to add this to the meaning of Compilation. Compilation significantly differs from interpretation or converting in the sense that when compilation is done machine codes are stored in a file or in memory. When interpretation is done machine codes are never stored. Interpreters just read the code line by line and parse it converting it to machine code but never store it.


JIT COMPILER
JIT Compiler compiles source code or intermediate code (like bytecode, MSIL) to machine code and store it in memory. That is it "cache" it. I believe we understand "Cache". In Computer Storage Technology, one of the least rudimentary computer storage is Cache. JIT does not only do compilation but also interpret the source code/intermediate code at runtime at first run to at least third run of the code.
In operation, JIT Compiler interprets the source code/intermediate code and at thesame time compiles the code. After two or three runs, JIT Compilers no longer interprets, it just straight away run the code in the machine code already cached.

Conventional Compilers
These Compilers compile all the source code/intermediate code and store them in a file on the system.
For example:
For C Language:
When you code in C you save as .c extension like app.c
When you give this file "app.c" to a C - Compiler it first create a file called app.o
Then it begins to read your codes and compiles them storing them into app.o
Note: Your .o extension means Object File.
Now that the compiler has stored the machine code (like x86 cpu code) into app.o then it can then run the code directly from app.o
About .exe files, a "linker" is used to connect the object file containing the machine code (app.o) with the .exe file like app.exe for execution.

For Java Language:
When you code in Java, you save as .java extension like app.java
When Java Compiler like "javac" the most used handles the app.java, it first create a file of .class extension like app.class
Then it reads the code and compiles it to byte-code by storing the byte-code inside app.class file.
The work of "javac" in Java Development Kit (JDK) ends as soon as it compiles Java Source Code to byte-code and stores them inside app.class.
Then Java Virtual Machine (JVM) in Java Runtime Environment (JRE) takes it from the point at which the Compiler stop and run the byte-code by interpreting/parsing/converting it to machine code just as explained above under Interpreters.
Therefore, app.class containing byte-code is run directly by JVM Interpreter.
Simply put, In Java Programming two things happen.
1. Java Source Code is compiled to byte-code
2. Byte-code is interpreted at runtime.

@ Micodon this is the area I was expecting you to hit when I asked you under which category will you classify Java and C#, because the two of them compiles to an intermediate code by storing them in a file system and also interprets the intermediate language. So when one talks about compiled languages the duo can fit in. When you talk about interpreted languages the duo too fit in.

The cunning way of JIT compilers comes in here as it also compiles and interprets. And the difference is clear that JIT stores in memory while conventional compilers stores inside a file system. Also, JIT storage technique is not done once like conventional complilers. JIT stores procedurally by getting the functions that is run and compile them to machine code. Just as Micodon said which is the basic principle behind JIT compiler, 'it is used to optimize the performance of interpreters, so that when the code is run more than once it can optimize it for the subsequent runs.
"Anyway at your discretion"

To be on the safer side, I believe we can say;
Compiled languages, Interpreted languages and Hybrid Languages (Compiled and Interpreted)

Finally, just as I have said any language can be compiled or interpreted. Anybody can work on JavaScript Programming to do compilation by storing in a file system. One can develop a compiler that will create a file to store machine code and run the JavaScript code directly from the file containing the cpu code. But without that for now our JIT/AOT Compilers have helped solved the issue of slow - slow.

Observation: JIT Compiler does not compile only byte-code. Like V8 Engine, its JIT Compiler compiles directly to machine code. JVM JITs, Rhino etc are the once I know that do that.

Thanks.

The key is: Precompilation. Languages that are precompiled by the developer are generally called compiled languages

And take note that compiling to Java Bytecode is not just a Java implementation. With Java's bytecode loader specifications, you can write a compiler to compile any language to java bytecode for the JVM. that's how languages like groovy, Scala and Clojure works.

Java can be compiled directly into native code by the developer if he so wishes. but compiled code may not be platform independent. hence, the JVM