deps: update V8 to 6.1

[targos]

In progress because:

• SmartOS must be fixed properly upstream (ref)
• Waiting for the merge of v8/v8@d8e37c3 in 6.1 (ref)
• 6.1 is still in beta

/cc @nodejs/platform-smartos @nodejs/v8

CI: https://ci.nodejs.org/job/node-test-commit/11673/

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• commit message follows commit guidelines

Affected core subsystem(s)

V8

[bnoordhuis]

Thanks, LGTM.

parallel/test-cluster-send-handle-large-payload is flaky for me too (locally, with master) so probably not related.

parallel/test-windows-failed-heap-allocation looks like it might though?

[misterdjules]

@targos

SmartOS must be fixed properly upstream

Is your target date for merging this still early September as previously mentioned in nodejs/node-v8#8?

[refack]

WOW we're down to two floating patches. Great work upstreaming 🥇

[refack]

If this is semver-major, maybe we can drop VS2013 support? /cc @nodejs/node-gyp @nodejs/release

1. For the general public, both VS2015 & VS2017 have free C++ build tools
2. Assumption is, if someone is locked into VS2013 they are unlikely to upgrade a node major version.

[bnoordhuis]

I'm +1 on dropping support for VS 2013 but it can't happen just yet if we plan on upgrading to v6.1 in node 8 (which is on the table, see #14220.)

[targos]

@misterdjules yes. Chrome 61 will be stable around Sep 5th.

[jbajwa]

@targos
Hi, could you kick off the V8 CI job https://ci.nodejs.org/job/node-test-commit-v8-linux/ with this PR? Thank you.

[refack]

@jbajwahttps://ci.nodejs.org/job/node-test-commit-v8-linux/855/

[targos]

Rebased.
New CI: https://ci.nodejs.org/job/node-test-pull-request/9687/
V8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/858/

[jbajwa]

@targos there are a couple of failures on ppc/s390. I'm working on fixing them.

[rvagg]

So we did have a not-explicitly-stated policy of not changing V8 2 months prior to going LTS, there's some discussion of it here: https://github.com/nodejs/LTS/pull/121/files#diff-04c6e90faac2675aa89e2176d2eec7d8R129 (PR never merged, not because it was rejected but because it was too much in one go and I lost steam, but discussion still stands).

It could be argued that TF+I makes this a special case because it is still stabilising and we're presumably going to benefit from it. However the original case also applies—we're locking ourselves in to a version and can't afford a major misstep going in to LTS or we could be tied to something that we regret but only realise too late; plus there's the expectation factor in that users should be able to predict what LTS is going to be like before it lands, no surprises!

Worthy of discussion though eh @nodejs/lts? I'd like to know what 6.1 gives us, particularly as it relates to TF+I. Anyone know?

[rvagg]

@targos can you update & rebase this PR so we can run it through CI again? I'm interested in the compiler compatibility story given the drama's we've had with 6.0 and the old glibc bug.

[targos]

@rvagg done

[evanlucas]

I'd like to know what 6.1 gives us, particularly as it relates to TF+I. Anyone know?

@rvagg My understanding is that 6.1 offers lots of performance improvements over 6.0, but I could be mistaken. /cc @nodejs/v8

[gibfahn]

However the original case also applies—we're locking ourselves in to a version and can't afford a major misstep going in to LTS or we could be tied to something that we regret but only realise too late

If it's ABI compatible with 6.0 (or shimmed to be), then we could always revert back if there were issues right?

[bricss]

V8 6.1 have some significant performance gain-> https://v8project.blogspot.com/2017/08/v8-release-61.html

[refack]

Does anyone know a node/V8 performance expert 👀 _@bmeurer...

If it's ABI compatible with 6.0 (or shimmed to be), then we could always revert back if there were issues right?

Theoretically true, realistically I don't see that happening.

---

I (can't believe I'm writing this) don't think performance is a strong enough incentive 🤷‍♂️ . There is another interesting notable-change asm.js is now validated and compiled to WebAssembly (And better WebAssembly debugging) which IMHO a stronger motivator.

[addaleax]

If it's ABI compatible with 6.0 (or shimmed to be), then we could always revert back if there were issues right?

So far we always shimmed for backwards compatibility only; if we want to have the option of reverting back, we’d technically need to disable new features from V8 6.1 as well.

[rvagg]

https://ci.nodejs.org/job/node-test-commit/11919/console still got git conflicts unfortunately

Target date for stable is Sept 5th so CTC is going to have to make a call on this I reckon. Either that or CTC could delegate the decision to the new Release WG?

Binary size reduction

This one's interesting, the removal of Crankshaft gives us a bit of an improvement in our binary size. Comparing the 6.2 v8-canary builds to nightly (https://nodejs.org/download/v8-canary/v9.0.0-v8-canary20170819c29776ec09/ vs https://nodejs.org/download/nightly/v9.0.0-nightly20170819467385a49b/) shows the V8 6.2 tarballs are ~95% the size of the current 6.0 tarballs and the node binary itself is ~93%, for Linux x64 at least. So that's neat.

[targos]

@misterdjules

I'm sorry, there was indeed a misunderstanding. I had a discussion about that on IRC with @cjihrig. He said that it was OK to merge this change as-is and that the correct one could be submitted later.

[misterdjules]

@targos

He said that it was OK to merge this change as-is and that the correct one could be submitted later.

Sounds good then!

[bmeurer]

Awesome work! 👍

[refack]

Woops completely missed the pings (nowadays I'm always on-line in IRC I case I'm needed in a rush)
For posterity: the AssertionError [ERR_ASSERTION]: 1 === 134 means the subprocess exited with code 1 (general error) and not the expected 134 (OOM).
This is probably because the JS layer throws RangeError: Invalid array length, because the _nn iterator grows to 2**32 too faster, and the heap does not get exhausted.