Is JavaScript running on top of web browser?
Like Java running on top of JVM?
Or Does it actually compiled to binary code and run on machine?
V8 (in Google Chrome) contains a JS interpreter and a JIT (Just-in-time) compiler. JS code is converted to V8-specific bytecode. The bytecode is initially interpreted by the interpreter, called "Ignition". When a function becomes "hot" (it is run a lot), the TurboFan JIT compiler produces optimized machine code from the bytecode.
Other modern JS engines use similar strategies. So JS can be interpreted or compiled to machine code (using a JIT compiler), similar to how JVMs work, yes.
Javascript isn't truly compiled - it's interpreted on the browser, so yes it effectively "runs on top of the browser" on the client side.
EDIT: I should've started by saying at it's base level. As is mentioned on a comment to this, there are more complex engines now.
It has to -- nothing can run on a computer without being the appropriate machine code for the processor.
V8 converts the JavaScript to its own byte code, then is heavily optimized and converted into machine code.
Even the JVM does something similar. The JVM converts the Java byte code into machine code.
Related
I recently started some web development, with ASP.NET and some Javascript, and something is confusing me alot.
I always read that JavaScript used to be interpreted until JIT slowly made it so chunks are compiled to machine code (which made browsers alot faster).
This makes no sense to me. How can JavaScript compile to native machine code, if traditional JavaScript apps don't target the machine/CPU to begin with?
I understand if an electron.js app gets compiled to machine code using the NodeJS runtime. That I get. Because it natively compiles to machine code and as far as I understand it, doesn't run in a browser.
If traditional JavaScript apps run in a browser, why must it be compiled to machine code? The browser is responsible for running the code, not the CPU. The CPU runs the browser itself. I actually don't see how the native OS can influence anything that happens in the browser at all or vise versa. Seems like a security issue as well.
Sorry if it's a stupid question, but I can't find any resource that will go beyond saying "Javascript uses JIT"
Thank you!
Lauren
At the end of the day, the CPU has to run the code.
JIT-compiling it down to machine code is one way to make that faster.
How can JavaScript compile to native machine code, if traditional JavaScript apps don't target the machine/CPU to begin with?
It is not "Javascript" that is doing it, it is the browser (or rather, the Javascript execution engine inside the browser), and since it is "JIT" it knowns exactly which CPU to target (this is not done in a generic way, this is done for the specific CPU that the browser is currently running on).
So, yes, there is some mismatch, since Javascript will not use low-level primitive types that the CPU can work with directly, which is why there is a lot of indirection and speculative type inference guess-work. The resulting machine code is much different than you would get from hand-coded assembly, but it can still be a net positive. To help with this, WASM was developed, which is closer to "normal" machine code.
Other intermediate, non-CPU specific formats like JVM bytecode or CLR bytecode or LLVM bitcode are in a similar situation (in that can also be compiled to machine code they do not themselves target directly) -- but they have been "lowered" already from language source code to something close to machine code.
Seems like a security issue as well.
Yes, it can be. The browser has to be careful in what it is doing here, and the OS should sandbox the browser as much as possible.
Executing instructions is easier than running an interpreter, and JIT seeks to take advantage of this for a performance boost. All programs running on your computer become machine code at some point, the only question is which instructions are be executed.
let x=0;
for (let i=0;i<100;++i) {
x+=2;
}
Since it is clear that there are no side effects in a block of code like this, it is faster to compile instructions directly, rather than interpreting each line.
// NIOS 2 assembly, sorry its the only one i know
movi r2,0
movi r3,0
movi r4,100
loop:
addi r2,2
addi r3,1
blt r3,r4,loop
Executing this will be faster than executing the parsing logic for each individual instruction.
TLDR: All programs are always running CPU instructions, so it is faster to minimize the number of instructions by skipping the parsing stage when possible
I'm aware of Emscripten and LLVM, but neither are written in JavaScript intended for a browser.
As far as I can tell, the tools exist, but they haven't been put together, but I could very well be missing some key factor that makes it very difficult to compile C++ to JavaScript in a browser.
So I'll mention my naive implementation:
Compile Emscripten to C, then use Clang to compile it to LLVM, then use Emscripten to compile it to JavaScript.
Compile Clang to LLVM, then compile that to JavaScript through Emscripten.
Write some C++ and run it through JavaScript Clang, then run that LLVM through Emscripten to get JavaSscript
Run the resulting JavaScript!
I'm sure I'm missing something from my steps. Please let me know, and let me know if there are any efforts by the community to resolve those missing pieces.
EDIT: JSCPP is the closest I've found, but it lacks a lot of features and frankly the author took on an absurd undertaking, by trying to rewrite the parser etc. on his own, rather than using existing tools. Still, close and pretty neat.
It is possible to compile C++ to JavaScript using a self-hosting version of Emscripten that runs in a browser, such as emception.
Alternatively, it is possible to run a C++ compiler (or even an entire operating system) using an x86 emulator in JavaScript.
Is JavaScript translated from source code to machine code with a JIT compiler or an interpreter? Or does it depend on the browser and the JavaScript engine you are running?
Javascript is an interpreted language.It is directly interpreted by browsers for execution.
But,modern browsers support JIT compilation which converts it to bytecodes for high performance.
JavaScript is scripting language and browser is executing scripts which are in text format. So by definition that makes JavaScript interpreted language.
Compiled languages are those which are executed from binary files.
JIT compilation is just something that JavaScript engines can do as way of optimization, but you never truly generate binary JS files, so language is interpreted one.
Does the V8 engine that is used in Chrome and Node.js compile the entire code to machine language once or it compiles the next context to be executed every time for each context that is added to the call stack ?
V8 will likely compile some of your code to machine language and likely not compile all of it to machine language.
The exact representation for any piece of code depends on many factors, including the ever-changing optimization behaviors in the library. None of it is guaranteed and shouldn't be treated as such, even if it behaves a certain way right now.
I’ve noticed that after making a change to a javascript file, clearing the cache, and reloading; one function in particular runs in about 90ms, the next time I load the page, it runs in 40ms, the next time I run it, it runs in 20ms … then never gets faster.
It kind of looks like IE is compiling my javascript and caching that compiled version somewhere, similar to how SQLServer processes queries.
Is that what is happening?
Does anybody know where I can find a clarification of how browsers process javascript?
You may want to check out Eric Lippert's comment to Peter Torr's blog post Compiled, interpreted, whatever:
JScript Classic acts like a compiled language in the sense that before any JScript Classic program runs, we fully syntax check the code, generate a full parse tree, and generate a bytecode. We then run the bytecode through a bytecode interpreter. In that sense, JScript is every bit as "compiled" as Java. The difference is that JScript does not allow you to persist or examine our proprietary bytecode. Also, the bytecode is much higher-level than the JVM bytecode -- the JScript Classic bytecode language is little more than a linearization of the parse tree, whereas the JVM bytecode is clearly intended to operate on a low-level stack machine.
The post and the comment are from September 2003, but judging from Ralph Sommerer's On JavaScript performance in IE8 post, they haven't changed much in the underlying JScript engine:
Unless the JavaScript engine used in IE (and elsewhere) employs some sort of compilation to native code, it will always lag behind its competitors with respect to performance. From what I gather in their Channel9 appearance they have made improvements in bytecode execution, but their main targets were JavaScript native objects (Array, String, ...) and JavaScript-DOM-interaction.
IE8 is not open-source, so one can only make hypotheses; however, open-source browsers (such as Chromium, Firefox, Webkit) do work roughly as you say, as do many other interpreters in non-browser and not necessarily JS settings (compile new sources when first seen or reloaded, cache or save the compiled version for faster execution in the future), so it seems very reasonable that IE's Javascript approach should be very much the same, as you surmised.
I know you asked about IE8, but here is V8 - Google's engine. Includes videos on how V8 works.
http://code.google.com/p/v8/