what is JavaScript engine and how it work?

September 14, 2020 | By admin | Filed in: Google chrome, JavaScript, JS Engine.

My name is white devil. I’m a CSE Student  and I work on the V8 JavaScript Engine. V8 is the JavaScript Engine that isused inside of Google Chrome. V8, the V8 project was started in late 2006. And at that time,the JavaScript implementations and browsers were not very advanced. And we wanted to dosomething about that and we wanted to try to push the performance spot, the JavaScriptexecution. And so, the best way to that is to implement our own JavaScript Engine fromscratch, so that’s what we did. So, most implementations at the time were interpreters of some form,so either operating on the “s” on bytecodes, so there is no native code generation forJavaScript. 

And, well, they were just pretty slow and the memory management systems weren’tvery good, good either. So basically, in order to do something that would really move thepicture, we decided to start from scratch and build a new JavaScript Engine. And afterbuilding the engine, we open sourced everything as is the case with all of Google Chrome,but it’s the case with V8 as well that everything is open sourced.

 And the reason for doingthat is that we want to push the performance of JavaScript Engines in general, not justfor Google Chrome, but for all the browser vendors. So, all of the ideas that we’ve usedinside the V8 to make V8 fast are accessible to anyone. You just look at the code and it’sunder a very free BSD license, so you can use it for anything you like, be it a commercialproducts or free software. So, really, the goal for V8 is to push the performance pathto JavaScript in the industry. 

Not just to Google Chrome, not just to Google, but forall of the browsers so that it will generate better browsers in general. So, some of thethings that we’re doing right now to speed up JavaScript performance is working on anew compiler. So right now, we have a compiler and it’s doing very well. But we know thatthe compiler can be faster, so generate the code faster, which means better start-up time.And we know that we can generate better code and there are a lot of things that we cando there, which will make a difference. 

One of the things that we can do is generate morethan one version of code, so we can generate an optimized version of codes that’s goingto be really fast. And then, if we hit something that the fast version of the code cannot handle,we can bail out and generate a slower version of the code that can handle all of the specialcases. So that’s one of the things we’re working on. Another thing that we’re working on isredesigning our snapshotting mechanism. So, we have a snapshotting mechanism in V8 thatallows us to take parts of the heap and put it in a binary format that we can use forother instances of V8. 

So, we try to generalize that so we can do more with that. So, oneof the things that we’re trying to do right now is generalize the snapshotting mechanismso that more of the work that V8 has to do on start-up can be stored in snapshot, thenwe just load, which gives us more instant start-up. We’re also just doing, like, tuningof the existing system. 

There are always things to improve. So, one of the things that we’rereal looking at, currently, as well is to make the transition between our generatedcode, which is running most of the time, and the run time system faster. So, if there’ssomething that our generated machine code cannot handle, we transition to the runtimesystem. And right now, that’s fairly heavy and we can make that lighter which will increaseperformance as well. 

Another area of optimization that we’re also working on is DOM manipulations.So, when accessing the DOM through JavaScript, we use the V8 API. And we’re, currently,working on optimizing that as well, so that DOM manipulations will get faster. So, the150% improvement in JavaScript speed, I think that’s from the initial Chrome launch upto the current release. Some of the things that we did here, so first of all, we shouldnotice that these speed improvements are relative to some benchmarks, right? Some of the improvementsthat we did to get those speed improvements are to implement a new compiler. 

So, I justsaid that we’re implementing a new one again and we are, because we did get even better.But we already did re-implement the compiler once to get a registered allocation, whichhelps for performance. In the compiler, we also did more in-lining, which improves propertyaccess speed. We also implemented a new regular expression engine completely from scratch.What we had before was not very good for V8’s purposes. 

It didn’t fit our model very well.So, we decided to design and implement our own Java–sorry, regular expression engine.And that gave a noticeable boost in performance as well. It gave, like, a factor of 10 onregular expression execution performance. So, those are some of the things that we’redoing. And then, we’re just doing, as I said before, tuning at the existing system.So, we’re just profiling the system in different–on the different working conditions and findingbottlenecks, and making sure to get rid of them.

 So, some of the things that we’vedone is avoiding allocations and–like delaying allocations of objects until we actually needthem. Where sometimes we would allocate objects upfront where we really didn’t have to.So, stuff like that. Just, like, tuning the system, finding bottlenecks, doing, yeah,doing tuning. Removing some operations that are not needed in the common case and onlydo those separations if we hit an oncoming case. Benchmarks are important. They’re veryhot to come up with because you want something that makes sense.

 So, we’re measuring ourselves against pretty much anything that we can find, because measuring ourselves, again,as much as possible is good for us, because we find trouble spots in V8. We find placeswhere we can do better and we can work on those. And also having as many benchmarksas possible is good for the user, right? 

Because it points out the situations where the differentJavaScript Engines are not doing as well as it could, and that keeps the implementerson their toes. So, we’re very happy about having benchmarks and so, basically, we measuredourselves about on anything that we can find which includes the V8 Benchmark Suite, whichis something that we launched at the time we launched Chrome. And that consists of anumber of benchmarks, most of them written by other people. A couple of them are standardobject-oriented benchmarks that have been used as benchmarks for other object-orientedlanguages. 

And leave it up to them for JavaScript and included them in the benchmark. A coupleof them are from real Websites, that’s Raytracer, encryption and decryption library. And recently,we’ve added a couple of extra benchmarks as well. So, when we did our new regular expressionengine? We needed a benchmark to measure our progress. So, what we did was look at 50 ofthe most popular websites on the web. Extract all of the regular expressions from thosepages and create a benchmark based on those regular expressions. 

So that’s one of theadditions that we’ve done recently. The other addition that we’ve made recently is to puta bit of focus on scalability. So, in order to run very big Web applications, or manyWeb applications in a number of tabs, you want to be able to scale well when it comesto the–a number of objects that you have in your JavaScript heap. And in order to scalewell, you need a good memory management system. So, we’ve created a benchmark that’s prettysimple, it just does a lot of splay-tree [ph] operations, which puts stress on the memorymanagement system. 

And so, that’s really our memory management system benchmark. And wethink that’s really important because it tells you something about the scalability of yourengine. And if you are running a big Web application, your JavaScript Engine will get under stresswhen it comes to memory management. There will be a lot of objects. So, if you get areally well-performing JavaScript Engine, there’s just more you can do on the clientas opposed to on the server, which gives you more flexibility as the producer of Web applications,and that’s a good thing. 

That’s good for the people producing the Web pages, the Web applications,and it’s good for the end-user to get better Web applications. So, I believe that JavaScriptperformance is a critical part of being able to create, like, the next generation of Webapplications that will have even more heavy use of JavaScript than what we’re seeing today. 

Leave a Reply

Your email address will not be published. Required fields are marked *