06/09/2010
Last time I studied the ability to embed javascript in nginx using the library Google V8 Javascript Engine , it should be noted, was no easy task, as all that complicated the classic "Hello World!", reflected in the documentation is extremely sketchy. Because V8 developed primarily for Chrome, then this left a significant imprint on him and, to paraphrase Henry Ford's statement about the color of the machine, it can be said that the V8 will work well in any application, provided that this program is called Chrome.
First of all, V8 does not know how to handle memory allocation errors - it just ends the process. This is acceptable for such a browser like Chrome, which displays each page in a separate process, and the crash of one process does not affect the other pages, but for the server to process in one process thousands of simultaneous connections, it does not fit. While V8 allows you to set your own error handler memory allocation, however, do something in the handler, other than completion of a process is not possible.
V8 executes scripts within contexts which represent a separate virtual machine. However, despite the fact that the concept of context can execute multiple scripts simultaneously, V8 support threads (threads) only in cooperative mode: a single process can be executed only one context, the other at the time to be active.
In the previous version of the article, I argued that a copy of an external object, such as in this case nginx HTTP-request in the context can be only one. This was due to the fact that FreeBSD/i386, where I spent my tests, V8 fell while trying to use a second instance of an object. This is also a phrase from it struck V8 Embedder's Guide :
However you can only have one instance of any template in any given context.
But later it turned out that FreeBSD/amd64 and other platforms several instances there is no problem. Time to create context - 2 milliseconds. Of course, when the context is created for each page in a browser, the user of these two fractions are not noticed, but the server will create a context for each request, it means that it can create a second to 500 contexts and, therefore, not be able to handle more 500 requests per second. Incidentally, the creation of the first context takes more than 20 milliseconds - this is due to the fact that part of the V8, for example, functions for working with strings and arrays, is written in Javascript '. And since Chrome each context in a separate process first, the developers have decided to accelerate its creation by snapshot'ov that javascript has been compiled in this case, the first context is created for the same 2 milliseconds. For the server, on the contrary, the time of creating the first context is not so critical, it is much more important when creating future contexts.
V8 uses automatic garbage collection, and the moment he chooses for this procedure, based on how this can best be done in the browser, which is not always convenient. However, some interface for the garbage collection is, for example, like this, you can call up to three times the procedure of partial garbage collection:
for (int i = 0; v8 :: V8 :: IdleNotification () && i <3; i + +);
Like Chrome, V8 currently only works on three platforms: i386, amd64 and arm. This is due to the fact that the V8 javascript compiles right into executable code, bypassing the stage of intermediate bytecode. By the way, initially supporting amd64 was not, she appeared in the summer of 2009. However, as the developers are working on normal V8 x86 computers, for faster debugging code that compiles to V8 architecture arm, was written by the simulator arm, which allows the arm to execute code on any platform. Theoretically, this simulator can be used for any special way unsupported platform.
Summarizing the above, we can say that at this point (version 2.0.6.4, February 2010) V8 is not suitable for installation in a serious server. Perhaps this situation will gradually change - for example, in summer 2009, the developers added a method v8 :: Script :: New compilation of context independent scripts, before the script was tied to the context in which it was compiled, it is appropriate for the browser, which compiles script and then once it does, and is not suitable for servers that perform the same script is thousands of times per second in different contexts.
(C) Igor Sysoev http://sysoev.ru