[8.x] deps: V8: backport 49712d8a from upstream#21334
[8.x] deps: V8: backport 49712d8a from upstream#21334ofrobots wants to merge 1 commit intonodejs:v8.x-stagingfrom
Conversation
deps/v8/src/wasm/wasm-js.cc
Outdated
There was a problem hiding this comment.
Seems like some merge conflicts sneaked in.
2da030f to
eeab6c1
Compare
|
Fixed the merge conflict. This didn't land cleanly on CI: https://ci.nodejs.org/job/node-test-pull-request/15511/ |
|
@nodejs/build @mhdawson the V8-CI seems to be hitting infra issues AFAICT. Any ideas? |
|
|
|
@mhdawson @nodejs/build ping. Several V8 back-port are blocked because of this. |
|
It's not happening on all V8 backports though. Maybe it's only happening to v8.x backports? |
The compiler level used on LinuxOne (s390x), ppcle Linux and AIX is based on the version of Node.js (i.e., >9): https://github.com/nodejs/build/blob/master/jenkins/scripts/select-compiler.sh |
|
There seem to be a few issues. I fixed IBM platform specific ones related to changes made to build with GN. But those were not what was reported here. opened nodejs/build#1370 as it seems to fail for other reasons on x86 for 10.x |
|
It seems to fail on V8.x without any other changes, @mmarchini confirmed it fails the same for V8.x-staging. |
|
Cleaned the workspace, if that still fails then my next guess is that something landed in v8.x v8.x-staging which broke it. Run on v8.x after cleaning workspace: https://ci.nodejs.org/job/node-test-commit-v8-linux/1456/ |
|
@richardlau I don't know what you are trying to point out? It fails across the board for v8.x including x86. |
|
Relaunched V8-CI: https://ci.nodejs.org/view/All/job/node-test-commit-v8-linux/1457/ |
|
Build to see if it passed on 6.x or not https://ci.nodejs.org/job/node-test-commit-v8-linux/1458/ It still failed on 8.x. If it passes on 6.x then I think its something in the 8.x line. . |
|
It failed on my PR branch. Here's a build of the |
|
Workspace clean then build on 6.x - https://ci.nodejs.org/job/node-test-commit-v8-linux/1460/ |
My apologies, I didn't spot that |
|
All failed. |
|
Failed for a different reason on 6.x. I'm wondering if it has to do with the google tooling required to build. @MylesBorins when was the last time these worked on 6.x and 8.x? |
|
|
|
we had V8 ci pass on 8.x-staging recently https://ci.nodejs.org/view/All/job/node-test-commit-v8-linux/1426/ |
|
@mmarchini mentioned his test run was on OSX not linux, so not necessary confirmation one way or the other. |
|
Same failures while running tests on another CI machine: I'm working on it, but might take some time to track down and fix this one. |
|
I was able to reproduce in an Ubuntu 16.04 x64 VM on my computer, so this is definitely not a problem with our infrastructure. Let me see if I can find when this started to happen. |
|
The other thing I noticed was it looks like the passing builds (10.x and later) use g++ while the failing ones use clang (8.x). Not sure why what would be the case. Also the failures on ppc and s390 look different, have asked @mmallick-ca to take a look at what might be going on there. Sounds like gclient sync is not pulling in something that is required. |
|
At this point I'll wait to see what @mmarchini figures out before spending any more time on this. |
|
New V8-CI: https://ci.nodejs.org/view/All/job/node-test-commit-v8-linux/1496/ @nodejs/lts @nodejs/v8-update this backport needs an LGTM before it can land. |
Original commit message: [wasm] Call AsyncInstantiate directly when instantiating a module object WebAssembly.instantiate is polymorphic, it can either take a module object as parameter, or a buffer source which should be compiled first. To share code between the two implementations, the module object was first passed to a promise (i.e. which is the result of compilation). However, passing the module object to a promise has a side effect if the module object has a then function. To avoid this side effect I remove this code sharing and call AsyncInstantiate directly in case the parameter is a module object. R=mstarzinger@chromium.org Bug: chromium:836141 Change-Id: I67b76d0d7761c5aeb2cf1deda45b6842e494eed4 Reviewed-on: https://chromium-review.googlesource.com/1025774 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{nodejs#52755}
eeab6c1 to
915ec4f
Compare
|
@nodejs/lts @nodejs/v8-update another ping. This needs an LGTM. A rubber stamp would do. |
|
|
|
Ooops, I intended to add the above to #21558. |
|
landed in 2afc05e |
Original commit message: [wasm] Call AsyncInstantiate directly when instantiating a module object WebAssembly.instantiate is polymorphic, it can either take a module object as parameter, or a buffer source which should be compiled first. To share code between the two implementations, the module object was first passed to a promise (i.e. which is the result of compilation). However, passing the module object to a promise has a side effect if the module object has a then function. To avoid this side effect I remove this code sharing and call AsyncInstantiate directly in case the parameter is a module object. R=mstarzinger@chromium.org Bug: chromium:836141 Change-Id: I67b76d0d7761c5aeb2cf1deda45b6842e494eed4 Reviewed-on: https://chromium-review.googlesource.com/1025774 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#52755} PR-URL: #21334 Reviewed-By: Michaël Zasso <targos@protonmail.com>
Original commit message: [wasm] Call AsyncInstantiate directly when instantiating a module object WebAssembly.instantiate is polymorphic, it can either take a module object as parameter, or a buffer source which should be compiled first. To share code between the two implementations, the module object was first passed to a promise (i.e. which is the result of compilation). However, passing the module object to a promise has a side effect if the module object has a then function. To avoid this side effect I remove this code sharing and call AsyncInstantiate directly in case the parameter is a module object. R=mstarzinger@chromium.org Bug: chromium:836141 Change-Id: I67b76d0d7761c5aeb2cf1deda45b6842e494eed4 Reviewed-on: https://chromium-review.googlesource.com/1025774 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#52755} PR-URL: #21334 Reviewed-By: Michaël Zasso <targos@protonmail.com>
Original commit message:
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passesThis effects
9.xas well, but I expect it is not worthwhile fixing there at this point./cc @nodejs/v8-update
V8-CI: https://ci.nodejs.org/view/All/job/node-test-commit-v8-linux/1425/