deps: update V8 to 5.7

[targos]

Marking in-progressbecause Chrome 57 is still in beta.
I'm also waiting on https://codereview.chromium.org/2736873005/ to drop the gyp patches.

Notable changes (source):

• faster promises and async functions
• faster spread operator, destructuring and generators
• faster RegExps
• new String methods: padStart and padEnd
• new Intl method: Intl.DateTimeFormat.prototype.formatToParts
• WebAssembly enabled by default
• PromiseHook C++ API (cc @trevnorris)

Checklist

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

/cc @nodejs/v8

[targos]

CI: https://ci.nodejs.org/job/node-test-commit/8325/
V8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/599/

[targos]

This is actually blocked on three issues that I forgot about:

• Build failures on Windows with 5.7-lkgr v8#4 (Build failure on Windows)
• Build failure on Ubuntu 12.04 with 5.7-lkgr v8#5 (Build failure on Ubuntu 12.04)
• Test failures on S390X with 5.7-lkgr v8#6 (Test failures on S390X)

[jasnell]

@targos ... just an update, I'll be cutting the 8.x branch next monday with an eye towards cutting the first release candidate on April 4th.

[Trott]

first release candidate on April 4th

You mean beta, right? Like, is there actually a chance that what you cut on April 4 will basically end up being the release?

[jasnell]

First beta will be next week after I cut the branch. The goal is to start stabilizing everything as quickly as possible with no more majors landing without CTC review after April 4th. Release candidate may be too strong but it should be more stable than beta. I'm going to be limiting minors also unless they've been in a 7.x release.

[bnoordhuis]

I'd say a little pragmatism is needed when it comes to V8 because we'll be stuck with that particular version for a long time. A glitch or two in the initial 8.0.0. release is perfectly okay if it means easier longer-term maintenance.

Also, WASM seems like a relevant enough addition for a LTS release.

Also also, I don't fancy fielding bug reports about the spread operator slowing down someone's script for the next couple of years.

[jasnell]

Oh indeed. The discussion on the ctc call today was that we would definitely land with 5.7 and hopefully with 5.8.

[bricss]

It would be awesome if it would be V8 5.8, the whole world count on this. 🤓

[targos]

@bricss What feature(s) from V8 5.8 do you count on?

[bricss]

WebAssembly should be enabled by default in V8 5.8 as I know.

[targos]

Yes, it is in 5.7:

$ ./node
> process.versions.v8
'5.7.492.63'
> WebAssembly.
WebAssembly.__defineGetter__ WebAssembly.__defineSetter__ WebAssembly.__lookupGetter__ WebAssembly.__lookupSetter__ WebAssembly.__proto__ WebAssembly.constructor WebAssembly.hasOwnProperty WebAssembly.isPrototypeOf
WebAssembly.propertyIsEnumerable WebAssembly.toLocaleString WebAssembly.toString WebAssembly.valueOf WebAssembly.CompileError WebAssembly.Instance WebAssembly.LinkError WebAssembly.Memory WebAssembly.Module WebAssembly.RuntimeError WebAssembly.Table WebAssembly.compile
WebAssembly.instantiate WebAssembly.validate 

[bricss]

Great, but also V8 5.8 would have performance improvements (new compilation pipeline) to deliver.

[NawarA]

+1 on delaying the Node v8.0.0 <Carbon?> by one week or two week, to include V8 5.8.

We delayed Node v6 Boron by a tiny bit, so we could include V8 5.1, which included Orinoco and major performance boosts (like Fast For-In loops) when compared to V8 5.0. This future proofed v6 LTS during its life-cycle.

I recommend we combine the Node LTS April release with the April release of V8 5.8 to do the same kind of future proofing. I believe V8 5.8 is stable around April 25th

[jasnell]

The 8.0.0 release will definitely go out in April. The current plan is the last week in April. If 5.8 is not ready by then, it won't make it. Hopefully it will be.

[fhinkel]

We removed the legacy JSON debugger protocol in V8 5.8. Not sure if including 5.8 in Node 8 would give people enough time to not rely on on the JSON protocol anymore.

[NawarA]

@fhinkel its a semMAJOR update, so devs expect a breaking change.

@jasnell thanks! With 6 LTS, we pushed 5.1 into the branch after release it was released. If we can't get 5.8 in by release date, can we expect it to be released into 8 LTS, when its ready? We did this with 6 LTS, so there is precedent, so I imagine its an option here as well. Is this an option?

[jasnell]

There are no guarantees but we can try. As @fhinkel points out, dropping the debugger is a significant change and we need to give users a proper deprecation cycle to transition to the new --inspect. We also need to make sure there are no ABI breaking changes (which we currently do not expect but we'll need to see for sure). The CTC would be looking at it and making a decision.

And while semver-major releases allow for breaking changes, our preference -- and the preference of many users -- is for those breaking changes to be kept to a minimum as much as possible. The runtime deprecation warning for --debug only just landed in v7.x within the past week or two. It really is important that we give users an opportunity to transition.

[icambron]

@jasnell I'm confused.

There are no guarantees but we can try.

That sounds like "if it's ready on time we can do it", whereas,

It really is important that we give users an opportunity to transition.

Sounds like "no, that is too abrupt, we need cut 8.0.0 without it regardless of its readiness". Can you clarify?

[jasnell]

It means that if there is time, it's stable, and the CTC is good with it, we'll land it. Otherwise we won't. We won't know until we're closer to the release date.

…

On Sat, Mar 11, 2017 at 1:11 PM Isaac Cambron ***@***.***> wrote: @jasnell <https://github.com/jasnell> I'm confused. There are no guarantees but we can try. That sounds like "if it's ready on time we can do it", whereas, It really is important that we give users an opportunity to transition. Sounds like "no, that is too abrupt, we need cut 8.0.0 without it regardless of its readiness". Can you clarify? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#11752 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAa2ed5x1hby_dW0QcaSQv66xKcKqWGRks5rkw4HgaJpZM4MXQWz> .