February 06 2011
[This is a response to this blog post by @olympum, with the rest of the thread being here and here.]
Bruno makes three assertions about the relationship between NodeJS and V8: that V8 was not designed as a server-side engine, that V8's lack of threading inhibits adequate fault isolation, and that lack of explicit alignment between the V8 and NodeJS projects may lead to problems in the future.
I'm not really sure what this means, as Bruno doesn't provide any details on what he's concerned about.
When compared with the JVM, which offers distinct client and server
modes affecting primarily JIT compilation garbage collection strategies,
V8 is indeed less full featured. In fact, in probably virtually all
respects, the JVM is more mature and featureful than V8. However, that
does not imply that it's a more appropriate choice for a server-side
JavaScript runtime. After all, the JVM was designed from the ground up
to run something vastly different than JavaScript. Though the list of
alternative languages targeting the JVM is long and growing, it's
unclear to me that supporting these is a priority for the JVM team (the
invokedynamic instruction not withstanding).
I would be very interested to see some benchmarks of workloads which are characteristic of server applications which compared Rhino, V8 and SpiderMonkey, et all. The results on arewefastyet.com are interesting, but don't include the JVM. Unfortunately, I'm not enough of a JavaScript expert to opine on the relevance of the benchmarks used there to a workload more classically "server". Perhaps someone else from the community could weigh in on this?
It would be wonderful if someone at Joyent or Yahoo! could contribute a representative benchmark (it's open source!) and/or include a JVM-based engine to AWFY.
This is a specious argument, IMO.
In a system which runs each request in its own thread, fault isolation is no better than a system which multiplexes requests over a single thread.
Let's examine what happens when a fault occurs in a thread-per-request model. In languages without direct memory access (JavaScript, Java, etc), faults in threads are bubbled up to the top of the thread stack, say by virtue of an exception. Other threads continue to soldier on in their work, unaffected by this. I think this is what Bruno is referring to. Of course, it is possible for a problem in one thread to cause others to fail, particularly by exhausting available resources (e.g. file descriptors, memory, database connections, etc). In addition, bugs in application synchronization will cause other threads to deadlock, see corrupted state, etc.
In a multiplexed model (e.g. NodeJS), things are largely the same: a fault will bubble up to the top of the event loop as an exception where it will be dealt with. Other requests are unaffected. Significantly, the lack of parallelism within the same address space suggests that this model may in fact be less likely to fail than a threaded model (no locking bugs!).
This argument boils down to which VM is more likely to crash of its own volition, taking all requests (be they in separate threads or not) with it. I don't have any information one way or the other on whether the JVM is more reliable than V8. Bruno, do you?
While there doesn't seem to be a formal commitment here, anecdotal evidence suggests that the V8 team is interested in seeing server-side JavaScript (and NodeJS in particular) succeed.
@jasonh makes several excellent points on the nature of this relationship (and Joyent's) in his blog post.