V8 engine how to implement JS, before the Webkit technology insider, but also just a glance. How does the Google V8 Engine work?

How does Google V8 work? That’s a very good question, and here’s a little official documentation that’s leaked to explain exactly what’s going on inside V8. I’ll share what I know with you (you’ll have to guess which parts I took out), and there are plenty of useful addresses to help you understand it.

V8 has two compilers:

  • A very simple and very fast compiler for thejsTo simple but slow mechanical code calledfull-codegen.
  • The other is a very complex real-time optimizer compiler that compiles high-performance executable code, calledCrankshaft.

V8 also uses some threads:

  • The main thread, which does what you want it to do: load your code, compile it, and execute it.
  • There is a separate compile thread that optimizes the code while the main thread executes.
  • aprofilerThreads (I don’t know if there are any, but there will be one thread with the same responsibility) to find out which method is taking the most time during execution, and so onCrankshaftYou can optimize the code.
  • Some are used toGCProcessing threads (here are some forGCMore than one thread is used for garbage collection).

When you first execute your code, V8 starts using full-codeGen, which translates JS code directly into mechanical code without any translation. This allows V8 to quickly execute mechanical code. Note that V8 does not use intermediate bytecode, so there is no need for translation processing.

When your code is executed, the profiler thread has enough data to figure out which methods need to be optimized. I’m not sure how V8 chooses which thread to use for this optimization, but let’s just say it uses the main thread for simplicity.

The main thread starts optimizing with Crankshaft by stopping the code that is executing (perhaps right where it needs to be optimized). The JS code is first compiled into a high-level description called Hydrogen, which is a static single-assignment representation of the control flow diagram. Most optimizations are done at this level.

First, inline as much code as possible, which makes optimization more meaningful. Then we do the type conversion. This optimization removes the packing and unpacking process and can be considered a lot of instructions executed. What that means is that if your code is operating on integers, and it’s not doing a cast, like a string, or a double, it’s going to run really fast. Inline caching plays an important role in this phase, providing type determination. As you can probably guess, we need to be careful with conversions: if you expect a variable to be an integer, but later it is changed to a different type, then your assumption fails and a recompile is inevitable. There are other optimizations, such as loop-invariant code motion, and the removal of dead code. Code that is not being executed should also be removed, otherwise V8 has to deal with it all the time, which is an extra burden), etc.

Once the Hydrogen Graph is optimized, Crankshaft will reduce it to a lower profile called Lithium. Most Lithium executes on a specific architecture. Registers are allocated at this level.

Eventually, Lithium was compiled into mechanical code. Then something called OSR (On-Stack replacement) happens. Remember, we like to execute a method that takes a long time to run before we start compiling and optimizing it. Let’s not forget that we just slowed down execution and started executing the optimized code. Instead, we will transform all contexts so that we can choose to execute the optimized code in the middle of execution. I’m going to complicate things for you, just to remind you, in other optimizations, we’ve inlined some things. V8 isn’t the only virtual machine to do this, but I’ve found some crazy places. There are some protection mechanisms called — to optimize, to do the opposite, and to reverse some optimized code in certain hypothetical situations.

There is. That’s the compile/execute part. I forgot to mention GC, but it’s short because I don’t know much about it.

For garbage collection, V8 uses the traditional method of tag-counting for garbage collection. The markup phase must stop JavaScript execution. To control GC costs and make execution more stable, V8 uses incremental markup. That is, instead of trying to mark every possible object in the heap, they process a portion of the heap and then resume normal execution. The next GC stops executing code and processes the previously unprocessed heap. This allows for very short pauses. As mentioned earlier, the scanning phase is handled by a separate thread.

posts tagged “v8”

Posts Tagged ‘v8’

V8 Resources

thlorenz/v8-perf

docs.google.com/document…

Floitsch. Blogspot. DE / 2012/04 / opt…

And here’s the source code