deps: upgrade to V8 4.7.80.24

[ofrobots]

Ref: #4085

Now that V8 4.7 has hit stable [0], this PR brings V8 4.7 onto master.

The PR includes all the cherry-picks from vee-eight-4.7 annd additionally 70405d4 was cherry-picked back from master.

Full change history for the 4.7 branch:
https://chromium.googlesource.com/v8/v8.git/+log/branch-heads/4.7

V8 blog post about what is new on V8 4.7:
http://v8project.blogspot.de/2015/10/v8-release-47.html

R=@bnoordhuis, @targos
/cc @misterdjules, @nodejs/v8
/cc @nodejs/build as this probably effects beta builds.

[0] http://googlechromereleases.blogspot.com/2015/12/stable-channel-update.html

[targos]

What about the semver label for this update ?
I remember @ofrobots saying that the V8 API didn't change between 4.6 and 4.7. Does it mean that modules don't need to be recompiled ? In that case I guess it would be semver-minor.
Or do we just always set it to semver-major for safety ?

[ofrobots]

As per the V8 API changes doc there shouldn't be embedder-exposed API changes in 4.7.

[cjihrig]

I thought 4.7 would go into master as semver-major and be released with Node v6.0.0 in April of 2016.

[evanlucas]

Won't we be way past 4.7 by April though?

[cjihrig]

Well yea, there would be other V8 updates along the way.

[bnoordhuis]

As per the V8 API changes doc there shouldn't be embedder-exposed API changes in 4.7.

Not at the API level but Context::GetEmbedderData(), Object::GetInternalField() and Object::GetAlignedPointerFromInternalField() in 4.7 aren't ABI-compatible with 4.6.

Which is a shame because otherwise it could have been a semver-minor in v5.x.

[bnoordhuis]

LGTM

[bnoordhuis]

CI: https://ci.nodejs.org/job/node-test-pull-request/899/

[ronkorving]

Wasn't the whole reason why io.js was born the fact that Node was falling way behind on ES6? If we stick V8 releases to semver major (and I get the argument, I really do), don't we fall into the same hole, because major releases are pegged to predetermined release dates?

[ofrobots]

@nodejs/build: From the CI, I cannot seem to access the jenkins results page for the lone failure on centos5-32. I consistently get '504 Gateway Timeout'. I can't know if it is a real failure or a flake. Any ideas?

[jbergstroem]

@ofrobots damn, thought I was able to fix all those timeouts. Looking at the raw log (https://ci.nodejs.org/job/node-test-commit-linux/nodes=centos5-32/ws/test.tap/*view*/) I can't see anything strange.

[jbergstroem]

not sure if thats a bug in the tap parser, can't find a single not ok.

[rvagg]

sorry the timeouts probably coincided with a couple of restarts I did

[bnoordhuis]

Wasn't the whole reason why io.js was born the fact that Node was falling way behind on ES6? If we stick V8 releases to semver major (and I get the argument, I really do), don't we fall into the same hole, because major releases are pegged to predetermined release dates?

To some extent maybe, but at least the release dates are predictable now and the release cycles short(er).

Apropos the 4.7 upgrade, what we could do (although I'm not sure if it's a good idea), is to apply some fixes to maintain ABI compatibility. I believe it's mostly a matter of moving some enums around. Thoughts?

[cjihrig]

I might be in the minority, but I like the idea of taking a new V8 in major versions, even if there are no breaking changes for native modules. My reasoning is the addition of new language features. As a userland module author, it is simpler to say "we will start using these new features, bump our own major version, and support this version of Node" when it is a major version bump. The hapi ecosystem did exactly this with Node 4 and its new ES6 features.

[trevnorris]

@cjihrig you're suggesting bringing the latest v8 into stable?

[cjihrig]

@trevnorris I'm suggesting only taking new V8s in major version bumps regardless of semver implications. So, in this case, not taking 4.7+ until Node 6.0.0.

[ofrobots]

@cjihrig I think feature testing is a better way to do language feature testing. JS devs, both on the browser and on Node.js are already familiar with how this works. What hapi team did is not really the norm, and shouldn't be used as the reason to hold back semver-minor features from other developers. Also, whether a semver-minor feature is 'part of the language' or not is a rather arbitrary distinction given how user-modifiable the language is.

@bnoordhuis Re: fixing the ABI compatibility issues. It is do-able. Back-porting fixes from upstream could theoretically become harder, but only if there is an actual conflict with our changes (not likely). I don't know there is any system-integrator (Debian?) that integrates Node with a system wide V8 library? We won't be ABI compatible with that version. Not sure if any such integrators exist.

[rvagg]

I'd like us to take V8 stables into master, we still haven't figured out our master/canary/next strategy but I'm under the assumption that most of us would like to have downloadable builds off master of some kind so that bleeding-edge types can use them and prepare us for the next stable release. I've been planning on starting a bikeshed on how to achieve this, I'll try and get to it asap and start a new issue for discussion but I was imagining something like automatic weekly builds with version numbers that make it clear it's not 5.x but it's also not quite 6.x and library authors shouldn't feel the need to support it yet.

[cjihrig]

I'm definitely not opposed to this landing in master, in case there was any confusion about that.

I think feature testing is a better way to do language feature testing.

Language feature detection is a huge pain. Rest parameters are in 4.7, right? You can't even load a file containing a rest parameter in current Node. Then you either have to maintain multiple versions of your code or use a transpiler.

[rvagg]

The long v0.11 saga is actually pretty instructive for us when considering a master release strategy and looking forward to further divergence between LTS and stable. There were open source libraries and even actual production deployments that were strictly v0.11-only because of some of the features available there and the fact that there was no v0.12 in sight. There were also many open source libraries that explicitly refused to add any support for v0.11 until v0.12 actually came out, we experienced a lot of that when trying to help add NAN support to addons (that mostly wore away as it started to look like we would never even see a v0.12).

I'm confident in the ecosystem's ability to adapt to the differences between versions and come up with both clever technical solutions and also policy solutions that will be suitable for different kinds of users. It may end up looking a little like a split but that's not such a bad thing and it'll work out over time with different users gravitating to different libraries and different policies over time. I have a lot of faith in our massive and very adaptive community to figure out how best to handle it; the best we can do is observe and respond with support where needed.

[mikeal]

@rvagg should we kick off a thread in the Build WG about a Canary strategy?

[geek]

If this does make it into a release, please make it a canary one... at least until 6.0.0 ships.

It doesn't make sense for code written on 5.x.x to not work on 5.x.x... amiright

[rvagg]

@geek yes of course, we're not going to break semver for this

[ofrobots]

I am going to land this PR to master later today.

[targos]

LGTM

[rvagg]

rubber-stamp lgtm