V8 in MongoDB

Those two follow node.js releases closely may have noticed that version 0.10 has taken a very long time to release, as contributions stagnated. Unable to follow Chrome's short release cycles, it stayed with a V8 version 3.14 that quickly became outdated. Fortunately, io.js was able to pick up the pace and now closely follows V8's releases.

A less well-known issue is MongoDB. Two years ago, MongoDB switched to V8 for its Javascript VM (from previously SpiderMonkey). However, that's where they stayed. Two years later, MongoDB is still using V8 3.12. There have been efforts to update to version 3.25, but seems to have been given up.

The issue seems to be that MongoDB expects V8 to handle out of memory situations more gracefully, but instead, as a result of architectural changes and bug fixes, V8 does not attempt to recover and intentionally crashes.

Given that V8 3.12 is now three years old, I wish something could be done here. Of course the Javascript code run on MongoDB are usually server-side, but given three years of security issues being fixed, I wouldn't be surprised if there are some exploits.

There is a bright counter-example: plv8 is very up-to-date as we speak, using V8 4.3, which is currently the most recent stable branch.

Improving V8's performance using the serializer/deserializer

V8 has long been using so-called snapshots to improve start-up time. By capturing a snapshot of a fresh V8 instance, initializing Javascript globals no longer require executing native scripts where they are defined, but simply deserializing the snapshot. A d8 shell built with snapshot starts within 15ms as opposed to 55ms without.

A minor sometimes overlooked detail is that the snapshot not only speeds up creating a V8 isolate via v8::Isolate::New, but also contexts created via v8::Context::New, as the snapshot is used as a template.

Recently, the serializer and deserializer implementing the start-up snapshot have been improved to support new features. In the following I want to give a brief introduction to two new embedder-facing APIs that - if used correctly - can improve performance significantly.

Caching JIT code

Javascript are a fundamental part of the web. Almost all popular browsers nowadays use a JIT compiler to compile Javascript code before executing it. For often visited sites, this seems like a waste of time and processing power: while the browser cache makes sure that those scripts do not necessarily have to be repeatedly fetched over the network, they still have to be compiled every time.

This may change in the near future. Even though not activated by default yet, you can take code caching out for a spin by starting the newest Chrome Canary on the command line, with the option

--v8-cache-options=code

or

--v8-cache-options=code-compressed

You can get a rough idea of what is happening if you add

--js-flags=--profile-deserialization

Give it a try!

Online books

The other day, while googling for a quote from George R. R. Martin's "A Song of Ice and Fire", I came across this site that simply hosts all the books in the series released up to date. While I'm quite certain that this violates copyright law, it sure is convenient, even though I own a paper copy of those books.

The site is hosted in Phoenix, Arizona. I wonder how long it will stay up until taken down.

It's a little known fact that Firefox's Spidermonkey has switched to a new RegExp engine recently. They abandoned YARR, which they took from WebKit's JSC a few years ago, and replaced it with the high-performance Irregexp from Chrome's V8. Porting it to Spidermonkey certainly was a tremendous job. As a result, their benchmark score on Octane/regexp improved a lot. (Orange for Firefox/Spidermonkey, green for Chrome/V8)

But for some reason, it's still pretty far away from V8's score in that particular benchmark. Let's speculate on why this is the case.

Debugging promises in Chrome

With the upcoming Chrome 36, Javascript Promises as specified in the upcoming revision of the ES6 standard are going to be activated by default as part of V8. Right now, you can already try it in the Dev or Canary release channels.

While a very useful addition to the language, especially with regard to asynchronous programming, Promises are peculiar when it comes to debugging: it swallows exceptions by default.

AKG k701 in anime

The other day I saw some nice wallpapers. Apparently, anime girls and headphones really go well together, as far as wallpapers are concerned. So I got a bit into researching. It turns out that some headphones that show up in animes are actually real products. Like AKG's k701, for example shown in K-ON.

That's actually a nice pair of headphones, from the looks of it. So I looked it up on Amazon. It's been on the market since 2008, and seems to be generally well-received. For around 200 Euros it's not too expensive.

However, I somehow doubt that most people, including Mio here, would use it to casually listen to music. The k701 is designed as studio headphones with open back, meaning it leaks sound to the environment. The advantage is of course a better sound. Another thing is that the k701 works best with the appropriate amplifier. Buying it to plug it into a portable music player of any kind is just a bad investment.

I guess the k701 is put there mainly because of its distinctive design. Nevertheless, it seems that I wasn't the only one whose attention was caught by those headphones.