Upgrade to V8 5.0.71.32 in master

[ofrobots]

Checklist

• tests and code linting passes
• the commit message follows commit guidelines

Affected core subsystem(s)

deps

Description of change

This PR is a rebase of vee-eight-5.0 (+ latest V8 5.0 lkgr) to master.

Normally we wait for V8 version to launch in Chrome stable before landing it onto master. Given that we are planning to start releasing RCs for Node v6 next week, it would be convenient to land V8 5.0 onto master sooner than normal. I expect that V8 5.0 will hit stable within the next couple of weeks.

Ref: #5945, #5766.
R=@nodejs/v8
/cc @nodejs/ctc
CI: https://ci.nodejs.org/job/node-test-pull-request/2217/ (5.0.71.31)
CI: https://ci.nodejs.org/job/node-test-pull-request/2258/

[jasnell]

@nodejs/ctc ... I would like to get this in before cutting the first release candidate for v6 on Monday afternoon but I'd like to get sign off first. If necessary, I can cut the release candidate as a branch off the vee-eight-5.0 branch rebased on the current master but, in general, I think it would be better to go directly off master.

[Fishrock123]

I think it would be safest to make the first RC off a PR/branch like this.

[Fishrock123]

@nodejs/benchmarking Could you run a special run off a branch for comparison, but not actually add to the usual graphs on the website?

[Fishrock123]

CC @nodejs/build something appears wrong with rpi 1: https://ci.nodejs.org/job/node-test-binary-arm/1657/

ERROR: Workspace has a .git repository, but it appears to be corrupt. 

[rvagg]

Since we have no guarantee that Chromium 50 will go stable in time I think this presents a risk for our schedule and I'd rather not lock it in like this. If 50 doesn't get out during this month then we're going to have to ship with 4.9 and update to 5.0 later on. Locking ourselves in to Chromium's release schedule would be irresponsible when we've put so much work in to communicating our release schedule. So my suggestion is that if you really want to include 5.0 in RC builds then do it off the vee-eight-5.0 branch.

[jasnell]

OK. Fortunately and unfortunately I'm behind schedule today so I won't be cutting the v6 RC1 until later this evening or tomorrow (likely tomorrow).

[bricss]

Chrome team have bumped canary branch to v52 it means that they should release v50 to stable in next few weeks, I hope so 🐙

[ofrobots]

Chrome 50 has launched. http://googlechromereleases.blogspot.com/2016/04/stable-channel-update_13.html

I have already updated this PR to the latest V8 5.0 lkgr. The CI looks green except for flakes.

[Fishrock123]

@ofrobots that means this version is the stable branch? (i.e. 5.0.71.x)

[ofrobots]

@Fishrock123 Chrome 50 is shipping with 5.0.71.32, the same as in this PR.

[santigimeno]

This is the first time I've seen this test failure in SmartOS:
https://ci.nodejs.org/job/node-test-commit-smartos/nodes=smartos14-64/2065/

# # assert.js:90 # throw new assert.AssertionError({# ^ # AssertionError: 'This is a unicode text: سلام' == '' # at process.<anonymous> (/home/iojs/build/workspace/node-test-commit-smartos/nodes/smartos14-64/test/parallel/test-http-default-encoding.js:36:10) # at emitOne (events.js:95:20) # at process.emit (events.js:182:7) # at process.exit (internal/process.js:79:15) # at ClientRequest.<anonymous> (/home/iojs/build/workspace/node-test-commit-smartos/nodes/smartos14-64/test/parallel/test-http-default-encoding.js:31:13) # at emitOne (events.js:90:13) # at ClientRequest.emit (events.js:182:7) # at Socket.socketErrorListener (_http_client.js:306:9) # at emitOne (events.js:90:13) # at Socket.emit (events.js:182:7) # connect ECONNREFUSED 127.0.0.1:12346 

I don't know if it is related or not though.

[ofrobots]

The ECONNREFUSED makes think it is a flake. Relaunched CI: https://ci.nodejs.org/job/node-test-pull-request/2255/

[targos]

@ofrobots can you please make sure #6179 is included?

[ofrobots]

Added the backport from #6179. New CI: https://ci.nodejs.org/job/node-test-pull-request/2258/.

[targos]

LGTM !

[bnoordhuis]

Rubber-stamp LGTM. Looks like the ARM failure is a flake; the test uses process.on('uncaughtException') - huge red flag. Are you going to squash the two upgrade commits?

[indutny]

Rubber-stamp LGTM

[ofrobots]

Thanks.

Squashed, landed as 6e3e8ac...b68827b. The fix from #6179 did not need to be reapplied.