deps: update V8 to 5.5 #9618

Open
wants to merge 6 commits into
from

Projects

None yet
@targos
Member
targos commented Nov 15, 2016 edited
Checklist
  • make -j8 test (UNIX), or vcbuild test nosign (Windows) passes
  • commit message follows commit guidelines
Affected core subsystem(s)

V8

Description of change

This PR updates V8 to the current 5.5-lkgr branch.

/cc @nodejs/v8

Previous discussion: nodejs/v8#2

CI: https://ci.nodejs.org/job/node-test-pull-request/4849/
V8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/417/
V8 CI: https://ci.nodejs.org/job/node-test-commit-v8-linux/422/

@Fishrock123
Member

As brought up in nodejs/v8#2 I'm quite skeptical this is a good idea until we get better hooks for native promises. (Which seemed to be the plan to get in before node version 8, where this was originally supposed to land.)

@mhdawson
Contributor

CI run to validate across platforms: https://ci.nodejs.org/job/node-test-commit-v8-linux/421/

@ilkkao ilkkao referenced this pull request in koajs/koa Nov 15, 2016
Open

Koa 2.0.0 #533

@bnoordhuis
Member

As brought up in nodejs/v8#2 I'm quite skeptical this is a good idea until we get better hooks for native promises.

That's a pretty cryptic comment on its own. I think the missing context is that 5.5 ships async/await without a flag?

@mhdawson
Contributor

Looks like CI failures across the board.

@jbergstroem
Member

Afaik smartos14 support is dropped for 5.5

@targos
Member
targos commented Nov 26, 2016 edited

Updated.

There are some new utf-8 fixes (1, 2) that make test/parallel/test-string-decoder fail. I'm sure that someone already mentioned it but I can't find the related issue.

Example failure:

test('utf-8', Buffer.from('F0B841', 'hex'), '\ufffd\ufffdA');
// AssertionError: Expected "\ufffd\ufffd\u41", but got "\ufffd\u41"

If I change the expected value, the error is inverted:

test('utf-8', Buffer.from('F0B841', 'hex'), '\ufffdA');
// AssertionError: Expected "\ufffd\u41", but got "\ufffd\ufffd\u41"
@ofrobots
Contributor
@targos
Member
targos commented Dec 3, 2016

I'm turning the PR into a clean semver-major that can land on master. I'll then open another one to backport to v7.x.

@targos
Member
targos commented Dec 3, 2016

This is still in progress because of v8@af842a7#commitcomment-19855022

@targos
Member
targos commented Dec 3, 2016

@nodejs/platform-smartos What are we going to do with SmartOS 14? The CI cannot be green because of the incompatibility with this platform.

@jbergstroem
Member

@targos as far as I know, it is to be dropped for 55 and forward. I can look at skipping testing against smartos14 for a specific node version; for instance 7.3?

@ofrobots ofrobots referenced this pull request in nodejs/promises Dec 5, 2016
Closed

Async/Await implementation in V8 #4

@misterdjules
Contributor

@targos FWIW, what @jbergstroem mentioned:

as far as I know, it is to be dropped for 55 and forward.

sounds good to me.

P.S: sorry for the delay, I was on vacation until today.

@pixelgrid

Hi everyone,
sorry for the offtopic question, but when when its v8(with 5.5 v8) scheduled to be released?

@gibfahn
Member
gibfahn commented Dec 19, 2016 edited

@pixelgrid See https://github.com/nodejs/LTS, Node.js v8 should be released in April 2017 (and will go LTS in October 2017).

@pixelgrid

@gibfahn so support for async/await from v8 5.5 is going to be cherry picked or is finally going to be set for deployment in april?

Is there any conserning performance of other issue that changed during 5.4 with a flag and 5.5 without one?

@kyptov
kyptov commented Dec 19, 2016

@pixelgrid #9339

@bricss
bricss commented Dec 20, 2016

Geez, I hope we would see backport of V8 5.5 in current Node.js branch in Q1 of 2017.

@jbergstroem
Member

I was under the impression that ABI/API will not change. True or false?

@ofrobots
Contributor
ofrobots commented Dec 22, 2016 edited

@targos trying to summarize current status. Let me know if anything is incorrect.

  • Deal with the string decoder tests that rely on undefined behaviour in the utf8 spec. I suggest that these tests be dropped. Tracking issue: #10300.
  • Drop SmartOS 14 testing in the CI for Node versions 8.0 onwards. @jbergstroem.

Others: let's keep the focus of this issue on landing V8 5.5 onto master. Whether or not this should be backported to the 7.x branch is a separate discussion out of scope from this issue.

@targos
Member
targos commented Dec 23, 2016

@ofrobots That is correct.

The string decoder thing is not just a test problem. There is an inconsistency between string_decoder and V8 and it has to be fixed. Tracking issue: #10300

@pannous pannous referenced this pull request in nodejs/NG Dec 23, 2016
Closed

WebAssembly #19

@targos
Member
targos commented Dec 30, 2016 edited

There is another question about CI support for Node 8+. I'd like to stop floating the deps: cherry-pick workaround for clang-3.4 ICE and I think there is a platform on CI that requires this patch.

@targos
Member
targos commented Dec 30, 2016

Also, as @mscdex pointed out in #10300 (comment), there are now two segfaults when tests are run with make test. It does not happen if the tests are run individually.

@MylesBorins
Member

/cc @jbergstroem and @nodejs/build re: @targos' question above

@gibfahn
Member
gibfahn commented Dec 30, 2016

There is another question about CI support for Node 8+

I think this probably comes under #8922

@targos
Member
targos commented Jan 1, 2017

Actually the failing test is test/parallel/test-trace-event.js and it does fail when run individually with ./node.

@targos
Member
targos commented Jan 1, 2017

/cc @matthewloring ^

Example failure

$ ./node --trace-events-enabled --trace-event-categories "" -e 'for (var i = 0; i < 100000; i++) { "test" + i }'
Warning: Trace event is an experimental feature and could change at any time.
*** Error in `./node': free(): invalid pointer: 0x0000000003971ce0 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x791fb)[0x7f76bff5e1fb]
/lib64/libc.so.6(+0x8288a)[0x7f76bff6788a]
/lib64/libc.so.6(cfree+0x4c)[0x7f76bff6b2bc]
./node(_ZN2v88platform7tracing17TracingControllerD1Ev+0xf1)[0x13cbeb1]
./node(_ZN2v88platform20SetTracingControllerEPNS_8PlatformEPNS0_7tracing17TracingControllerE+0x24)[0x13c75f4]
./node(_ZN4node5StartEiPPc+0x18c)[0x134016c]
/lib64/libc.so.6(__libc_start_main+0xf1)[0x7f76bff05401]
./node(_start+0x2a)[0x843f2a]
======= Memory map: ========
00400000-01ff8000 r-xp 00000000 fd:02 1073356                            /home/mzasso/git/forks/node/out/Release/node
021f7000-021f8000 r--p 01bf7000 fd:02 1073356                            /home/mzasso/git/forks/node/out/Release/node
021f8000-02210000 rw-p 01bf8000 fd:02 1073356                            /home/mzasso/git/forks/node/out/Release/node
02210000-02228000 rw-p 00000000 00:00 0
03959000-03ac1000 rw-p 00000000 00:00 0                                  [heap]
7f76b0000000-7f76b0021000 rw-p 00000000 00:00 0
7f76b0021000-7f76b4000000 ---p 00000000 00:00 0
7f76b4000000-7f76b4021000 rw-p 00000000 00:00 0
7f76b4021000-7f76b8000000 ---p 00000000 00:00 0
7f76b8000000-7f76b8021000 rw-p 00000000 00:00 0
7f76b8021000-7f76bc000000 ---p 00000000 00:00 0
7f76bd6e0000-7f76bd6e1000 ---p 00000000 00:00 0
7f76bd6e1000-7f76bdee1000 rw-p 00000000 00:00 0
7f76bdee1000-7f76bdee2000 ---p 00000000 00:00 0
7f76bdee2000-7f76be6e2000 rw-p 00000000 00:00 0
7f76be6e2000-7f76be6e3000 ---p 00000000 00:00 0
7f76be6e3000-7f76beee3000 rw-p 00000000 00:00 0
7f76beee3000-7f76beee4000 ---p 00000000 00:00 0
7f76beee4000-7f76bf6e4000 rw-p 00000000 00:00 0
7f76bf6e4000-7f76bf6e5000 ---p 00000000 00:00 0
7f76bf6e5000-7f76bfee5000 rw-p 00000000 00:00 0
7f76bfee5000-7f76c00a2000 r-xp 00000000 fd:01 1069042                    /usr/lib64/libc-2.24.so
7f76c00a2000-7f76c02a1000 ---p 001bd000 fd:01 1069042                    /usr/lib64/libc-2.24.so
7f76c02a1000-7f76c02a5000 r--p 001bc000 fd:01 1069042                    /usr/lib64/libc-2.24.so
7f76c02a5000-7f76c02a7000 rw-p 001c0000 fd:01 1069042                    /usr/lib64/libc-2.24.so
7f76c02a7000-7f76c02ab000 rw-p 00000000 00:00 0
7f76c02ab000-7f76c02c3000 r-xp 00000000 fd:01 1069060                    /usr/lib64/libpthread-2.24.so
7f76c02c3000-7f76c04c3000 ---p 00018000 fd:01 1069060                    /usr/lib64/libpthread-2.24.so
7f76c04c3000-7f76c04c4000 r--p 00018000 fd:01 1069060                    /usr/lib64/libpthread-2.24.so
7f76c04c4000-7f76c04c5000 rw-p 00019000 fd:01 1069060                    /usr/lib64/libpthread-2.24.so
7f76c04c5000-7f76c04c9000 rw-p 00000000 00:00 0
7f76c04c9000-7f76c04df000 r-xp 00000000 fd:01 1052354                    /usr/lib64/libgcc_s-6.3.1-20161221.so.1
7f76c04df000-7f76c06de000 ---p 00016000 fd:01 1052354                    /usr/lib64/libgcc_s-6.3.1-20161221.so.1
7f76c06de000-7f76c06df000 r--p 00015000 fd:01 1052354                    /usr/lib64/libgcc_s-6.3.1-20161221.so.1
7f76c06df000-7f76c06e0000 rw-p 00016000 fd:01 1052354                    /usr/lib64/libgcc_s-6.3.1-20161221.so.1
7f76c06e0000-7f76c07e8000 r-xp 00000000 fd:01 1069045                    /usr/lib64/libm-2.24.so
7f76c07e8000-7f76c09e7000 ---p 00108000 fd:01 1069045                    /usr/lib64/libm-2.24.so
7f76c09e7000-7f76c09e8000 r--p 00107000 fd:01 1069045                    /usr/lib64/libm-2.24.so
7f76c09e8000-7f76c09e9000 rw-p 00108000 fd:01 1069045                    /usr/lib64/libm-2.24.so
7f76c09e9000-7f76c0b61000 r-xp 00000000 fd:01 1058399                    /usr/lib64/libstdc++.so.6.0.22
7f76c0b61000-7f76c0d61000 ---p 00178000 fd:01 1058399                    /usr/lib64/libstdc++.so.6.0.22
7f76c0d61000-7f76c0d6b000 r--p 00178000 fd:01 1058399                    /usr/lib64/libstdc++.so.6.0.22
7f76c0d6b000-7f76c0d6d000 rw-p 00182000 fd:01 1058399                    /usr/lib64/libstdc++.so.6.0.22
7f76c0d6d000-7f76c0d71000 rw-p 00000000 00:00 0
7f76c0d71000-7f76c0d78000 r-xp 00000000 fd:01 1069069                    /usr/lib64/librt-2.24.so
7f76c0d78000-7f76c0f77000 ---p 00007000 fd:01 1069069                    /usr/lib64/librt-2.24.so
7f76c0f77000-7f76c0f78000 r--p 00006000 fd:01 1069069                    /usr/lib64/librt-2.24.so
7f76c0f78000-7f76c0f79000 rw-p 00007000 fd:01 1069069                    /usr/lib64/librt-2.24.so
7f76c0f79000-7f76c0f7c000 r-xp 00000000 fd:01 1069044                    /usr/lib64/libdl-2.24.so
7f76c0f7c000-7f76c117b000 ---p 00003000 fd:01 1069044                    /usr/lib64/libdl-2.24.so
7f76c117b000-7f76c117c000 r--p 00002000 fd:01 1069044                    /usr/lib64/libdl-2.24.so
7f76c117c000-7f76c117d000 rw-p 00003000 fd:01 1069044                    /usr/lib64/libdl-2.24.so
7f76c117d000-7f76c11a2000 r-xp 00000000 fd:01 1096033                    /usr/lib64/ld-2.24.so
7f76c136d000-7f76c1373000 rw-p 00000000 00:00 0
7f76c139b000-7f76c139c000 rw-p 00000000 00:00 0
7f76c139c000-7f76c139d000 ---p 00000000 00:00 0
7f76c139d000-7f76c13a2000 rw-p 00000000 00:00 0
7f76c13a2000-7f76c13a3000 r--p 00025000 fd:01 1096033                    /usr/lib64/ld-2.24.so
7f76c13a3000-7f76c13a4000 rw-p 00026000 fd:01 1096033                    /usr/lib64/ld-2.24.so
7f76c13a4000-7f76c13a5000 rw-p 00000000 00:00 0
7ffd49d11000-7ffd49d32000 rw-p 00000000 00:00 0                          [stack]
7ffd49d81000-7ffd49d83000 r--p 00000000 00:00 0                          [vvar]
7ffd49d83000-7ffd49d85000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
[1]    21327 abort (core dumped)  ./node --trace-events-enabled --trace-event-categories "" -e

@targos
Member
targos commented Jan 1, 2017 edited

@matthewloring I didn't follow the discussion at #9304. The PR added a file at src/tracing/trace_event.h that looks a lot like deps/v8/base/trace_event/common/trace_event_common.h.
I don't know how it was generated but I'm pretty sure we have to update it. Do you have a script or document on how to do that?

@matthewloring
Contributor

I am currently away, maybe @ofrobots or @kjin can take a look. Otherwise, I'll investigate when I'm back at work.

@jasongin
Contributor
jasongin commented Jan 5, 2017

I code-reviewed the tracing PR (and have been building on it), so I can help with these issues.

I just submitted a PR that fixes the trace test failure: #10623

Regarding src/tracing/trace_event.h, I think that should be updated with the changes from the new v8 version. It contains a complete copy of deps/v8/base/trace_event/common/trace_event_common.h, but with an additional ~600 added lines at the bottom. I don't know why that header was duplicated rather than #included, maybe @matthewloring can comment on that.

@matthewloring
Contributor

deps/v8/base/trace_event/common/trace_event_common.h was copied because it is implemented by the macros defined in deps/v8/src/tracing/trace-event.h which transitively depends on deps/v8/src/base and introduces macro definitions conflicting with those in node (equality assertions and some other utility macros). More generally, we don't want to depend on anything in deps/v8/src as it is not on the v8 public interface could could see more API churn.

src/tracing/trace_event.h should be updated but I have not created a script to do this in an automated way. I currently have very limited internet access but can look into automating the process when I'm back at work. In the mean time, this file should be completely unused by node (for now) so I don't think it should block the landing of this PR.

@targos
Member
targos commented Jan 6, 2017 edited
@jbajwa
Contributor
jbajwa commented Jan 6, 2017

@targos
It seems to be a gcc issue, we did hit a couple of similar ones before v8/v8@d8792ab, v8/v8@757ea24.
We didn't hit this one since we might not have this specific gcc version in our environment. Will put in a fix in master and backport to 5.5/5.6

@targos
Member
targos commented Jan 6, 2017

And our CI is finally green 🎉 (clang 3.4 and SmartOS 14 failures are expected)

@mhdawson
Contributor
mhdawson commented Jan 6, 2017

"benchmark,v8test" is linux x86 and I believe we build for 64 bit. I can get more specifics if you need.

@targos do you already have the fix from Jaideep ?

@targos
Member
targos commented Jan 6, 2017

@mhdawson no I don't have it.

@jbajwa
Contributor
jbajwa commented Jan 8, 2017
@targos
Member
targos commented Jan 8, 2017 edited

Trying a new run with the patch: https://ci.nodejs.org/job/node-test-commit-v8-linux/504/
Edit: it's green.

@targos
Member
targos commented Jan 8, 2017

@nodejs/build This PR will likely be ready to land in a few days. Are you ready to remove the SmartOS 14 and ubuntu1204-clang341-64 hosts from the tests on master?
@nodejs/ctc any objection to this?

@jbajwa
Contributor
jbajwa commented Jan 9, 2017

s390 patch is in V8 master and backported to 5.6/5.5

@ofrobots

Thanks for putting this together, looking great!

nit: It would be good to reword the abstract for a511fd7 to be more specific about the test.

Secondly, I think we should start bumping NODE_MODULE_VERSION on a semver major update of V8 (until NAPI becomes the stable native module interface). This was discussed in this CTC meeting, although a formalized proposal on this is yet to be written.

@jasnell
Member
jasnell commented Jan 10, 2017

+1 on bumping the NODE_MODULE_VERSION

@targos
Member
targos commented Jan 11, 2017 edited
@jbergstroem
Member

@targos: I can look over the weekend; if someone else from the build team wants to help out that'd be great though -- last time i checked how to skip through the build job it was pretty tedious (since things like tap parser assumes there is always output).

@targos
Member
targos commented Jan 17, 2017
@addaleax
Member

Should 9c4abc7 have a Fixes: tag?

@jbergstroem jbergstroem referenced this pull request in nodejs/build Jan 17, 2017
Open

skip v8 on smartos14 #595

targos and others added some commits Dec 23, 2016
@targos targos deps: update V8 to 5.5.372.40 6cf69ed
@mhdawson @targos mhdawson deps: limit regress/regress-crbug-514081 v8 test
regress/regress-crbug-514081 allocates a 2G block of memory
and if there  are multiple variants running at the
same time this can lead to crashes, OOM kills or
the OS failing to allocate memory.  This patch
limits us to running a single variant of the test

Fixes: nodejs#6340
PR-URL: nodejs#6678
Reviewed-By: Ben Noorhduis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Fedor Indutny <fedor@indutny.com>
935955b
@fhinkel @targos fhinkel test: move test-vm-function-redefinition to parallel
With the upstream fix in V8, function declarations now
work fine in the vm module and the test is no longer failing.

Refs: https://codereview.chromium.org/2334733002
Fixes: nodejs#548
1adf179
@targos targos src: update NODE_MODULE_VERSION to 52
V8 5.5 is not API/ABI compatible with 5.4.
This commit increments NODE_MODULE_VERSION by one.

Refs: https://github.com/nodejs/CTC/blob/master/meetings/2016-09-28.md
ce48da5
@targos targos repl: remove workaround for function redefinition
The issue is fixed upstream in V8. Thus we do not need this workaround
in REPL.

Fixes: nodejs#548
758c569
@mscdex @targos mscdex string_decoder: align UTF-8 handling with V8
V8 5.5 changed how invalid characters are handled and it now appears
to follow the WHATWG Encoding standard, where all of an invalid
character's bytes are replaced by a single replacement character
(\ufffd) instead of replacing each invalid byte with separate
replacement characters.

Example: the byte sequence 0xF0,0xB8,0x41 is decoded as '\ufffdA' in
V8 5.5, but is decoded as '\ufffd\ufffdA' in previous versions of V8.
96cd5f1
@targos
Member
targos commented Jan 17, 2017 edited

@addaleax correct. I replaced Refs with Fixes.

@bnoordhuis

LGTM. Can you fix my surname's spelling in commit 935955b while you're here? Thanks. :-)

@jbajwa
jbajwa approved these changes Jan 17, 2017 View changes
@klimashkin

Sorry for bothering
Is there a planned date (or week) for 7.5? Can't find a milestone or tracking issue

@SEAPUNK
SEAPUNK commented Jan 18, 2017 edited

@klimashkin From what it looks like, this PR will land in Node 8, which according to the LTS schedule, will be released sometime in April of 2017.

@jasnell
Member
jasnell commented Jan 19, 2017

As a semver-major this can land in master as soon as it is ready but cannot be backported into 7.x. The earliest release it could go into is 8.0.0.

@bricss
bricss commented Jan 19, 2017

Yep, but as far as we know V8 5.7 or even 5.8 will be release before planned release of Node.js 8.0.0. How we would deal with it? Skip versions 5.5 and 5.6 of V8 and deploy Node.js next major with newest fresh and juicy V8 or 6 month outdated V8 5.5 then? 😑

@kyrylkov
kyrylkov commented Jan 19, 2017 edited

@bricss Node semver-major usually ships with the latest stable V8 available before the Node release, so that will be 5.7 or 5.8 depending on the actual timing. As of today, V8 5.5 is the latest stable, but it doesn't mean it will land in Node 8.

@kyrylkov

@bricss Here is the right thread to follow #10117

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment