nginscript–: Why do we have to implement our own JS engine?

in last week'snginx.confat the user conference, we released a newJavaScriptengineNginscriptPreview version of the. Historically,JavaScriptlanguage has been applied in many ways, first as a client script and then used for server background development. AsNginscript, we are going to introduce the first kind of"Proxy Side"Used to meet the unique set of requirements we made at the meeting. After the announcement of the news, many people decided to make a newJavaScriptengine, rather than usingV8,SpiderMonkeyor other existing engines, so this article is used to explain why we do this.

What are we doing?
We are writing our ownJavaScriptengine, calledNginscript. Nginscriptcurrently supports parsersECMAScript 5a subset (which we will expand in the future), using a register-based virtual machine (VMS), the runtime compiles the code into bytecode, while supportingNginxand theNginx plus. In the current preview phase,Nginxcan compileJavaScriptcode and use in two scenarios: GenerateNginxconfiguration, or in theNginxThe execution phase generates content. Future versions will support more usage scenarios.

Why would you want to create your own JavaScript runtime?
NginxThere are special needs that lead us to create our own engines. In order to extend the processing flow of the request, we need toNginxcan run when a request is processedNginscriptfragment. We don't seek to create a backendJavaScriptApplication Execution Environment–becausenode. jshave done very well. The currentJavaScriptthe engine is designed to run in aWebin the browser, they rely on the garbage collector's management memory. If you run out of memory,JavaScript VMsexits abnormally, and this behavior is tolerable for browsers. However, for servers that hold thousands of connections, the engine specifically designed for the browser is not suitable for the server, includingV8,SpiderMonkeyThey do not provide an easy way to control execution (that is, the mechanism for preventing crashes and restoring virtual machines), while supportingJITcapacity is limited. We want to have an engine that willNginscriptscripts are simple and fast to execute. At the same time, the resulting state is saved outside the virtual machine. Because the script is simple, full supportJavaScriptlanguage is not necessary. Meanwhile,Nginxalready has a very granular event-driven architecture, and we don't want toNginxperformance is affected by the garbage collector.

Instead, we are creating a very simple engine to meet our requirements:
Architecture– with a single thread, the execution portion of the bytecode will be very fast. Assign a virtual machine to each request. Because there is no complex state to initialize, this simple virtual machine can be started quickly while managing memory with a simple cache pool. This memory management scheme can greatly improve performance by eliminating the need to track and release individual objects or use the garbage collector.
Accessibility features –nginxmany built-in operations are implemented. For example, complex mathematical operations, hash functions, and when nginscript and nginx are combined, these operations are also local. You can use nginscript to programmatically drive nginx 's native methods.
and nginx fit –nginx Event-driven model can be used to schedule execution. When a nginscript is performing blocking operations (such as reading network data), nginx You can pause the VM VM The event is complete and then resumed. This means that you can write a simple script, The dispatch script does not cause blocking. Finally, with our own engine, we can guarantee that the api unify while ensuring our VM nginx supported platform range consistent.

?

about Performance
It's too early to talk about performance, and we're currently focusing on the implementation of the feature. nginscript is compiled into internal bytecode and runs on a register-based virtual machine; This mechanism makes it and other explanatory languages (PHP,Ruby , and so on) performance is comparable. So to improve performance, we want to increase JIT compilation in some places , but this may limit the supported platform scope. nginscript is simply designed to execute some simple internal scripts, and we don't want it to perform computationally intensive operations, because nginx Internals are based on C The language module has solved this problem.

Future
Nginscriptcurrently in its early stages of development, we call the current version"Preview"version. We will focus on the implementation of core languages (such as adding closures) and implement many built -inJavaScriptObject (date, math, and so on).
We will also focus on how to integrate resources, such asNginxHow the configuration integrates the script, in what waysNginscriptcan access and controlNginxinside? How do you share data between scripts, and across clusters? How Users DebugNginscriptscript?
for long-running scripts, such asWebSocketwe can even add a garbage collector, but that's in the future a long time later.
forNginscriptThere is no conclusion as to how the future will develop. We would like to receive your feedback. Share your thoughts and insights in our mailing list and we will work together to develop this feature. Thank you.

nginscript–: Why do we have to implement our own JS engine?