Update V8 to 3.15

[isaacs]

http://v8.googlecode.com/svn/tags/3.15.11.2/

[indutny]

@isaacs we should upgrade to some version with my fix for postmortem debugging data: v8/v8@2dcfba5.

I've asked @erikcorry about it here https://chromiumcodereview.appspot.com/11676005/

[bnoordhuis]

Feel free to drop a25ebb1 and 1e738c5 when upgrading, it looks like those changes won't get accepted upstream.

On a separate note, 3.15 has a lot of new API functions that let you specify the isolate. That's a good thing because V8 usually spends about 3-4% of CPU time in pthread_getspecific(), looking up the isolate.

[indutny]

See #4505 for reference. Landed.

[indutny]

There's a problem with this v8 version: https://code.google.com/p/v8/issues/detail?id=2468

Apparently, 3.14.5 seems to be working more stable... though, it has old APIs and I suggest we should try waiting for v8 team to fix that 3.5.11 regression...

[isaacs]

This is landed in master. Unless some new information comes to light, we'll keep using 3.15. From the v8 team via @indutny, we'll be following 3.15 closely as some fixes are expected to be backported from bleeding-edge.

[milani]

I guess the issue is fixed. May someone please update v8?

[bnoordhuis]

@milani We downgraded to 3.14 in b15a10e due to performance/stability issues.

[jbergstroem]

@bnoordhuis I'd like to know more about the relationship between nodejs and v8. Is the overall plan to stick closely to v8 stable releases, or is that of less importance? There's obviously enough reasons to stay off from the rapidly moving upstream, but also raises potential maintenance issues.

[bnoordhuis]

@jbergstroem We preferably ship a recent stable release but for now that's not an option. Let's hope the issues get resolved in the v0.12 dev cycle.

[dougwilson]

@jbergstroem if you are interested, this was the biggest issue with 3.15: Issue 2551: String::Utf8Length() absurdly slow for lefty cons strings. Node was using 3.15.11.15 before the rollback and now there is 3.15.11.16 (which is what the latest stable Chrome is using) that has the path from that issue, but it is pointed out in the issue that it is still massively slow compared to 3.14.

[erikcorry]

This is fallout from a change in Webkit. It used to be that Webkit had only 2-byte (UTF-16, more or less) strings. V8 had ASCII strings (that can be converted to UTF-8 with memcpy) and 2-byte strings. The 2-byte strings sometimes had shared storage with Webkit strings (external strings in V8 usage).

Now WebKit has support for 1-byte Latin1 strings. See https://bugs.webkit.org/show_bug.cgi?id=66161 This means that if V8 wants to share storage with WebKit, which it does, it has to support Latin1 strings too. It's too painful for V8 to support 3 different kinds of strings (2-byte, Latin1 and ASCII), so ASCII support was dropped. Unfortunately the Latin1->UTF-8 transformation is not nearly as simple as the ASCII->UTF-8 transformation, and this is an issue for node.