Why Google V8 is not suitable for integration into servers
from: http://translate.google.com/translate?js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&sl=ru&tl=en&u=http%3A%2F%2Fsysoev.ru%2Fprog%2Fv8.html
nginx author's talk about integration v8 into web servers
Why Google V8 is not suitable for integration into servers
09.06.2010
Last time I was studying the possibility to embed javascript in nginx with a library of Google V8 Javascript Engine , that it must be noted, was no easy task, since all that complicated the classic "Hello World!", reflected in the documentation is very sketchy.
Since V8 is developed primarily for Chrome, it left a significant imprint on him and, to paraphrase Henry Ford's statement about the color of the machine, we can say that the V8 will work well in any program, provided that the 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 a browser like Chrome, which displays each page in a separate process, and the crash of one process does not affect the rest of the pages, but for a server that is processing in a single process thousands of simultaneous connections, it does not fit. Although V8 allows you to set your error handler to allocate memory, however, to make a handler something other than the completion of the process, it is not possible.
V8 executes scripts within the context, which is essentially a separate virtual machine. However, despite the fact that the concept of contexts allow for multiple scripts in parallel, V8 supports streams (threads) only in cooperative mode: a single process can run only one context, and the rest at this time to be inactive.
In the previous version of the article, I argued that a copy of an external object, for example, in case it nginx'a HTTP-request, in the context can be only one. This was due to the fact that the FreeBSD/i386, where I conducted the tests, V8 fell when trying to use a second instance of the object. At the same phrase it struck from the V8's Guide Embedder :
However you can only have one instance of any template in any given context. 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, multiple instances of operating without problems.
Of course, when the context is created for each page in the browser, the user, these two fractions are not noticed, but if the server will create a context for each request, it means that it can generate per second to 500 contexts and, therefore, not be able to handle more 500 requests per second. By the way, creating 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'e. And since Chrome each context in a separate process first, then the developers 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 ms. For the server, on the contrary, the time of creating the first context is not so critical, far more important during a later context.
V8 uses automatic garbage collection, and the moments he chooses for this procedure, based on how this can be done better in a browser that does not always convenient. However, some interface to work with 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++); for (int i = 0; v8:: V8:: IdleNotification () & & i <3; i + +);
Like Chrome, V8 at the moment only works on three platforms: i386, amd64 and arm. This is due to the fact that the V8 compiles javascript directly into executable code, bypassing the stage of an intermediate byte-code. By the way, initially to support amd64 no, she appeared only in the summer of 2009. However, since the developers are working on the V8 common x86 computers, to speed up the debugging code that compiles for the V8 architecture arm, was written by the simulator arm, which allows you to arm the code on any platform. Theoretically, this simulator can be used for any unsupported platform in a special way.
Summarizing the above, we can say that at the moment (version 2.0.6.4, February 2010) V8 is not suitable for serious embedded in servers. Perhaps this situation will change gradually - for example, in summer 2009, the developers added a method for v8:: Script:: New to compile scripts independent of context, and before the script was tied to the context in which it was compiled, which is suitable for the browser, which compiles script and then once it does, and is not suitable for servers that perform the same script thousands of times per second in different contexts.
(C) Igor Sysoev
http://sysoev.ru
nginx author's talk about integration v8 into web servers
Why Google V8 is not suitable for integration into servers
09.06.2010
Last time I was studying the possibility to embed javascript in nginx with a library of Google V8 Javascript Engine , that it must be noted, was no easy task, since all that complicated the classic "Hello World!", reflected in the documentation is very sketchy.
Since V8 is developed primarily for Chrome, it left a significant imprint on him and, to paraphrase Henry Ford's statement about the color of the machine, we can say that the V8 will work well in any program, provided that the 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 a browser like Chrome, which displays each page in a separate process, and the crash of one process does not affect the rest of the pages, but for a server that is processing in a single process thousands of simultaneous connections, it does not fit. Although V8 allows you to set your error handler to allocate memory, however, to make a handler something other than the completion of the process, it is not possible.
V8 executes scripts within the context, which is essentially a separate virtual machine. However, despite the fact that the concept of contexts allow for multiple scripts in parallel, V8 supports streams (threads) only in cooperative mode: a single process can run only one context, and the rest at this time to be inactive.
In the previous version of the article, I argued that a copy of an external object, for example, in case it nginx'a HTTP-request, in the context can be only one. This was due to the fact that the FreeBSD/i386, where I conducted the tests, V8 fell when trying to use a second instance of the object. At the same phrase it struck from the V8's Guide Embedder :
However you can only have one instance of any template in any given context. 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, multiple instances of operating without problems.
Of course, when the context is created for each page in the browser, the user, these two fractions are not noticed, but if the server will create a context for each request, it means that it can generate per second to 500 contexts and, therefore, not be able to handle more 500 requests per second. By the way, creating 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'e. And since Chrome each context in a separate process first, then the developers 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 ms. For the server, on the contrary, the time of creating the first context is not so critical, far more important during a later context.
V8 uses automatic garbage collection, and the moments he chooses for this procedure, based on how this can be done better in a browser that does not always convenient. However, some interface to work with 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++); for (int i = 0; v8:: V8:: IdleNotification () & & i <3; i + +);
Like Chrome, V8 at the moment only works on three platforms: i386, amd64 and arm. This is due to the fact that the V8 compiles javascript directly into executable code, bypassing the stage of an intermediate byte-code. By the way, initially to support amd64 no, she appeared only in the summer of 2009. However, since the developers are working on the V8 common x86 computers, to speed up the debugging code that compiles for the V8 architecture arm, was written by the simulator arm, which allows you to arm the code on any platform. Theoretically, this simulator can be used for any unsupported platform in a special way.
Summarizing the above, we can say that at the moment (version 2.0.6.4, February 2010) V8 is not suitable for serious embedded in servers. Perhaps this situation will change gradually - for example, in summer 2009, the developers added a method for v8:: Script:: New to compile scripts independent of context, and before the script was tied to the context in which it was compiled, which is suitable for the browser, which compiles script and then once it does, and is not suitable for servers that perform the same script thousands of times per second in different contexts.
(C) Igor Sysoev
http://sysoev.ru