On Bruno’s Concern About the Current Coupling of node.js and V8

Bruno Fernandez-Ruiz (Yahoo! Fellow, VP and Platform Architect) wrote about his concerns around the current tight coupling between node.js and V8. Feel free to take a moment and read the original article: “NodeJS: To V8 or not to V8”.

A reply doesn’t fit into a twitter response, and an update mentioning my reply would be great.

Overall, it’s a valid concern, partially enforced by the fact that we’ve left the github page titled “Evented I/O for V8 javascript”. We have debated this internally and have intended to correct it. It is also currently true: Node.js is only implemented on V8 but that’s only because we’re going to focus on making node.js awesome first.

I haven’t had a chance to meet Bruno, we’ve only exchanged a couple of emails in the past. Bruno forgot or doesn’t know a couple of key things about node.js and Joyent. I’m always happy to talk about development process at Joyent.

Because I actually have answers to his questions, comments and concerns, I’m going to reply below. They are trimmed down and if I’ve missed one in particular, please let me know in the comments.

Update: Bruno took the time to follow-up with responses to my queries, while former Yahoo Principal Engineer (and current “Desperado at Facebook“) Peter Greiss has waded into the debate as well.

Bruno: “I have been saying for a while that server-side Javascript matters.”

Yes, agreed. You’ve both been saying it and SSJS does matter.

Bruno: “NodeJS is currently tightly coupled to Google’s V8 engine.”


Bruno: “V8 was not designed as a server-side engine, but as a browser-based engine.”

I don’t know what this means, or if there’s a difference. More details here would be helpful.

Bruno: “It’s software that was not designed to run on a server.”

I’d also like to know exactly what this means, and more details would be helpful.

Don’t even get me started on language virtual machine implementations, just go ahead and compare the quality of V8 with Ruby. I would say something about PHP but the honest truth is that it’s been years and years since I’ve cared about it and my opinions are out-dated.

Bruno: “It’s really up to Google to work with the community to make V8 work on the server-side.”

Up to a point. It’s actually Joyent’s responsibility that node.js runs well period. We’re not afraid of a language VM.

Bruno: “Sometimes Google is responsive, but sometimes it might not [sic].”

Yes, that might be the case. I generally find that responsiveness is aided by a few of things: Previously working with members of the other core team at the same companies, functioning as a real contributor when there’s an issue (e.g. don’t report a bug unless you have a patch) and actually participate in cutting quality code (e.g. adding DTrace and other instrumentation capabilities into V8).

Bruno: “It varies as it depends how fixing a bug or applying a patch may align with Google’s product roadmap and plans.”

That doesn’t matter to us. If there’s an issue with V8 that affects node.js, we’ll fix it. If the patch never makes it into the mainline V8 tree, well … then it looks like we’d be a branch that would continue to track it. We have experience doing this.

Some examples: We “branched” the Solaris 11 Kernel in 2005 and tracked all Nevada put backs for 5 years (this did eventually lead to a full fork); we’ve been a NetBSD pkg-src user and contributor for 4 years; we worked with Apple on the version of Ruby (with DTrace probes) that shipped back with Leopard.

If we end up in a situation like OpenSolaris’s dissolution, then we’ll do what we did then: We’ll fork it. And fork it hard. Fork it like it’s never been forked before.

Let me pull a recent example from Bryan Cantrill’s blog:

Speaking of systems vets, a highlight of JSConf.eu was hanging out with Erik Corry from the V8 team. JavaScript and Node owe a tremendous debt of gratitude to V8, without whom we would have neither the high-performance VM itself, nor the broader attention to JavaScript performance so essential to the success of JavaScript on the server-side. Erik and I brainstormed ideas for deeper support of DTrace within V8, which is, of course, an excruciatingly hard problem: as I have observed in the past, magic does not layer well — and DTrace and a sophisticated VM like V8 are both conjuring deep magic that frequently operate at cross purposes. Still, it was an exciting series of conversations, and we at Joyent certainly look forward to taking a swing at this problem.

Bruno: “I don’t Google’s plans [sic], and I suspect most NodeJS committers don’t know either.”

I’m under the impression that actual node.js committers (who all work at Joyent) know quite a bit and have pretty good relations with the V8 team. If they didn’t, we’d address it, we’d come up with evidence for our concerns, then we’d actually fix it and we’d put it back.

Bruno: “But to Yahoo!, and to others, it’s a big deal and we believe this is fundamental to the success of the NodeJS project.”

Joyent is the company behind node.js. I’m one of two founders of Joyent. You have an e-mail from me in your inbox from months ago. Respond to it. We have product people on node.js, business people on node.js and Ryan’s there leading it and doing all final commits.

Bruno: “Writing a Javascript runtime that does not fail is hard.”

I don’t know what you mean my “fail”. Is this actual failures, you’ve been burned by a bug recently or do you mean “OHAI FAIL?”

Bruno: “Even the really smart V8 folks have explicitly designed V8 for failures to happen and safeguard the browser. In a browser, a JS engine failure it’s an inconvenience to the user: damn, you lost a tab. In a thread-per-request blocking I/O server design it’s also not a big deal, you lose one in-flight request. But in an event-driven web server, it’s a major flaw, you lose thousands of in-flight requests you have already accepted.”

OK. Reliability is important in event’ed systems under load. I don’t think you’ll get any disagreement there.

Has this happened to you? Is there something in particular?

I think your point is that failures (e.g. in a PHP stack?) will not impact as many requests because it’s “thread-per-request blocking I/O server design” and less scalable and slower on a per process basis. Interesting arguments.

One key step is actually instrumenting in production. This first link is to an image showing some examples of this in V8 and node.js. The second link, I’d recommend coming back to it later.

Bruno: “For NodeJS to scale to billions of page views like Yahoo!’s, we need to make sure the Javascript engine / VM behind Node is rock-solid for server-side loads, i.e. it fails extremely rarely.”

Yes, ok. Example please.

I mean you need to understand that we use node.js as the core in our instrumentations, agent designs, API end-points, machine-to-machine work and a large-scale telemetry system.

Besides our use, I can safely say that we’re the world’s experts in instrumenting it within a complete system context.

Bruno:“Google may invest on supporting V8 on the server-side, just like the Mozilla folks do.”

Understand that we started using V8 after years of using Spidermonkey and other javascript VMs on the server-side both at Joyent and at Sun. At Joyent, we’ve been using SSJS in production for 4 years. For the former-Fishworkers on the team, the entire backend, shell and tools of the “Sun ZFS Storage 7xxx” series is in C and javascript.

Bruno:“Or somebody else might invest and ensure V8 is rock-solid on the server and Google may merge the patches nicely.”

You think? Node.js is not being worked on in a vacuum.

Bruno: “Or maybe not, and the community may need to fork V8. Or something else … Nobody really knows.”

Actually, I do know. We’re engineers at Joyent and we like working on hard problems.

Perhaps a complaint would be “but Joyent is a start-up!”

Yes, we’re a 7 year old start-up with offices in San Francisco, Vancouver, Geneva, the People’s Republic of China and Singapore; we’re a start-up that rarely depends on outside software engineering in what we ship and we’ve been either deploying or shipping globally for years; we’re a “start-up” that’s made it on the Gartner Magic Quadrant for Infrastructure as a Service (the criteria for inclusion there is clear), will be on the one for Platform as a Service and we’re an “enabler” that ships to global telcos too.

And finally, you’ll notice that we did sell a chunk of the company to Intel at the end of 2009 and now even share a board member. I don’t see us being worthless or failing anytime soon. (Tab back to the board, see any VCs there?)

The closest complaint is that we’re “stealthy” or perhaps the historical lack of marketing people combined with plenty of geeks suggests we don’t shout often enough about how awesome we are.

Perhaps a comment would be “but Joyent can’t actually work on or contribute to a language VM!”

Well. Actually we could. We come from companies like Intel, Sun Microsystems, Oracle, Google, Apple, Amazon Web Services, Microsoft, Sprint, AT&T, Verizon and Exodus.

We love working on hard shit and we already work on kernels, userlands, virtualization methods, runtimes and there’s even unique things that we do.

We also hire people and tweet about it (that tweet is from last year).

And by the way, if you know anyone that’s interested in a software engineering gig working on V8 (with the intent of helping with Google’s Project), let me know.

Bruno: “Either way, it’s time for the NodeJS community to realise there is a roadblock and discuss it openly.”

Let’s talk about community. I like open source projects that are focused on source code, and detailed, clear discussions about technological strengths and weaknesses. Once the API, abstractions et cetera for node.js are what one could call stable, then there can be work done to take the same API, abstraction and methods to other Javascript VMs. First things first.

If there are actual technical problems with V8’s reliability and these affect the use of node.js in production then I’d like to see details, and if another large company is capable of contributing, then I’d love to see a patch.

After all, we are still working on getting it to 1.0.

14 thoughts on “On Bruno’s Concern About the Current Coupling of node.js and V8

  1. Question: “V8 was not designed as a server-side engine, but as a browser-based engine.”
    Answer from blog post: “I don’t know what this means, or if there’s a difference. More details here would be helpful.”

    Just found a nice article from nginx author:


    Original post if from beginning of 2010 (written in russian).

    Another issue is well known upper memory limit for node.js processes 🙂

    1. Great link to that article. It sums up a couple of the potential issue quite well: that a “server” VM must be robust and reliable in it’s error handling. The good news is that it’s an addressable problem.

      For the near future, I’m not too worried about a 4GB upper limit per process.

  2. Pingback: Code.DanYork.com

Comments are closed.