deps: V8: cherry-pick b49206d fom upstream by ofrobots · Pull Request #20727 · nodejs/node

ofrobots · 2018-05-14T20:15:36Z

Ref: #20083

Original commit message:

ThreadDataTable: Change global linked list to per-Isolate hash map.
For use cases with a large number of threads or a large number of isolates (or
both), ThreadDataTable can be a major performance bottleneck due to O(n)
lookup time of the linked list. Switching to a hash map reduces this to O(1).
Example 1: Sandstorm.io, a Node.js app that utilizes "fibers", was observed
spending the majority of CPU time iterating over the ThreadDataTable.
See: https://sandstorm.io/news/2016-09-30-fiber-bomb-debugging-story
Example 2: Cloudflare's Workers engine, a high-multi-tenancy web server
framework built on V8 (but not Node), creates large numbers of threads and
isolates per-process. It saw a 34x improvement in throughput when we applied
this patch.
Cloudflare has been using a patch in production since the Workers launch which
replaces the linked list with a hash map -- but still global.
This commit builds on that but goes further and creates a separate hash map
and mutex for each isolate, with the table being a member of the Isolate
class. This avoids any globals and should reduce lock contention.
Bug: v8:5338
Change-Id: If0d11509afb2e043b888c376e36d3463db931b47
Reviewed-on: https://chromium-review.googlesource.com/1014407
Reviewed-by: Yang Guo yangguo@chromium.org
Commit-Queue: Yang Guo yangguo@chromium.org
Cr-Commit-Position: refs/heads/master@{#52753}

Checklist

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

CI: https://ci.nodejs.org/job/node-test-pull-request/14871/
V8-CI: https://ci.nodejs.org/view/All/job/node-test-commit-v8-linux/1368/

Original commit message: ThreadDataTable: Change global linked list to per-Isolate hash map. For use cases with a large number of threads or a large number of isolates (or both), ThreadDataTable can be a major performance bottleneck due to O(n) lookup time of the linked list. Switching to a hash map reduces this to O(1). Example 1: Sandstorm.io, a Node.js app that utilizes "fibers", was observed spending the majority of CPU time iterating over the ThreadDataTable. See: https://sandstorm.io/news/2016-09-30-fiber-bomb-debugging-story Example 2: Cloudflare's Workers engine, a high-multi-tenancy web server framework built on V8 (but not Node), creates large numbers of threads and isolates per-process. It saw a 34x improvement in throughput when we applied this patch. Cloudflare has been using a patch in production since the Workers launch which replaces the linked list with a hash map -- but still global. This commit builds on that but goes further and creates a separate hash map and mutex for each isolate, with the table being a member of the Isolate class. This avoids any globals and should reduce lock contention. Bug: v8:5338 Change-Id: If0d11509afb2e043b888c376e36d3463db931b47 Reviewed-on: https://chromium-review.googlesource.com/1014407 Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{nodejs#52753} PR-URL: nodejs#20727 Ref: nodejs#20083

bnoordhuis

LGTM. New CI because the previous one bombed on infrastructure issues:

https://ci.nodejs.org/job/node-test-pull-request/14877/

ofrobots · 2018-05-17T18:16:41Z

New CI was all green: https://ci.nodejs.org/job/node-test-commit/18544/. Landing.

ofrobots · 2018-05-17T18:25:38Z

Landed in 0ebbd76.

Original commit message: ThreadDataTable: Change global linked list to per-Isolate hash map. For use cases with a large number of threads or a large number of isolates (or both), ThreadDataTable can be a major performance bottleneck due to O(n) lookup time of the linked list. Switching to a hash map reduces this to O(1). Example 1: Sandstorm.io, a Node.js app that utilizes "fibers", was observed spending the majority of CPU time iterating over the ThreadDataTable. See: https://sandstorm.io/news/2016-09-30-fiber-bomb-debugging-story Example 2: Cloudflare's Workers engine, a high-multi-tenancy web server framework built on V8 (but not Node), creates large numbers of threads and isolates per-process. It saw a 34x improvement in throughput when we applied this patch. Cloudflare has been using a patch in production since the Worker launch which replaces the linked list with a hash map -- but still global. This commit builds on that but goes further and creates a separate hash map and mutex for each isolate, with the table being a member of the Isolate class. This avoids any globals and should reduce lock contention. Bug: v8:5338 Change-Id: If0d11509afb2e043b888c376e36d3463db931b47 Reviewed-on: https://chromium-review.googlesource.com/1014407 Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#52753} PR-URL: #20727 Ref: #20083 Refs: #20083 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: James M Snell <jasnell@gmail.com>

KoenLav · 2018-05-21T21:58:40Z

@ofrobots is there anything still needed to get this into Node.js 8?

ofrobots · 2018-05-21T22:12:46Z

@KoenLav the process we follow is that a fix first has to be available on the current release line before it is considered for back-porting to LTS by the @nodejs/release team. I have attached the labels above which will make this fix show up on the list of potential back-ports to the LTS releases.

It is going to take a little while before you see it on 8 LTS – but the objective is to make sure we have adequate feedback from the current line to avoid disrupting the LTS lines.. /cc @nodejs/release in case I got anything wrong about the release process.

Original commit message: ThreadDataTable: Change global linked list to per-Isolate hash map. For use cases with a large number of threads or a large number of isolates (or both), ThreadDataTable can be a major performance bottleneck due to O(n) lookup time of the linked list. Switching to a hash map reduces this to O(1). Example 1: Sandstorm.io, a Node.js app that utilizes "fibers", was observed spending the majority of CPU time iterating over the ThreadDataTable. See: https://sandstorm.io/news/2016-09-30-fiber-bomb-debugging-story Example 2: Cloudflare's Workers engine, a high-multi-tenancy web server framework built on V8 (but not Node), creates large numbers of threads and isolates per-process. It saw a 34x improvement in throughput when we applied this patch. Cloudflare has been using a patch in production since the Worker launch which replaces the linked list with a hash map -- but still global. This commit builds on that but goes further and creates a separate hash map and mutex for each isolate, with the table being a member of the Isolate class. This avoids any globals and should reduce lock contention. Bug: v8:5338 Change-Id: If0d11509afb2e043b888c376e36d3463db931b47 Reviewed-on: https://chromium-review.googlesource.com/1014407 Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#52753} PR-URL: #20727 Ref: #20083 Refs: #20083 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: James M Snell <jasnell@gmail.com>

veered · 2018-06-22T19:04:18Z

@ofrobots Any idea on when this might land in Node 8? It'll be a huge deal for the Meteor community :)

ofrobots · 2018-06-22T21:22:50Z

@MylesBorins is this on track for a 8.x release?

MylesBorins · 2018-06-25T18:26:21Z

@ofrobots this is going to need a manual backport to 8.x

ping @nodejs/v8-update

ofrobots · 2018-06-25T19:29:50Z

8.x backport: #21529

This is the v8.x backport of nodejs#20727. Original commit message: ThreadDataTable: Change global linked list to per-Isolate hash map. For use cases with a large number of threads or a large number of isolates (or both), ThreadDataTable can be a major performance bottleneck due to O(n) lookup time of the linked list. Switching to a hash map reduces this to O(1). Example 1: Sandstorm.io, a Node.js app that utilizes "fibers", was observed spending the majority of CPU time iterating over the ThreadDataTable. See: https://sandstorm.io/news/2016-09-30-fiber-bomb-debugging-story Example 2: Cloudflare's Workers engine, a high-multi-tenancy web server framework built on V8 (but not Node), creates large numbers of threads and isolates per-process. It saw a 34x improvement in throughput when we applied this patch. Cloudflare has been using a patch in production since the Worker launch which replaces the linked list with a hash map -- but still global. This commit builds on that but goes further and creates a separate hash map and mutex for each isolate, with the table being a member of the Isolate class. This avoids any globals and should reduce lock contention. Bug: v8:5338 Change-Id: If0d11509afb2e043b888c376e36d3463db931b47 Reviewed-on: https://chromium-review.googlesource.com/1014407 Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{nodejs#52753} Backport-PR-URL: nodejs#21529 PR-URL: nodejs#20727 Refs: nodejs#20083 Refs: nodejs#20083 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: James M Snell <jasnell@gmail.com>

This is the v8.x backport of #20727. Original commit message: ThreadDataTable: Change global linked list to per-Isolate hash map. For use cases with a large number of threads or a large number of isolates (or both), ThreadDataTable can be a major performance bottleneck due to O(n) lookup time of the linked list. Switching to a hash map reduces this to O(1). Example 1: Sandstorm.io, a Node.js app that utilizes "fibers", was observed spending the majority of CPU time iterating over the ThreadDataTable. See: https://sandstorm.io/news/2016-09-30-fiber-bomb-debugging-story Example 2: Cloudflare's Workers engine, a high-multi-tenancy web server framework built on V8 (but not Node), creates large numbers of threads and isolates per-process. It saw a 34x improvement in throughput when we applied this patch. Cloudflare has been using a patch in production since the Worker launch which replaces the linked list with a hash map -- but still global. This commit builds on that but goes further and creates a separate hash map and mutex for each isolate, with the table being a member of the Isolate class. This avoids any globals and should reduce lock contention. Bug: v8:5338 Change-Id: If0d11509afb2e043b888c376e36d3463db931b47 Reviewed-on: https://chromium-review.googlesource.com/1014407 Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#52753} Backport-PR-URL: #21529 PR-URL: #20727 Refs: #20083 Refs: #20083 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: James M Snell <jasnell@gmail.com>

nodejs-github-bot added build Issues and PRs related to build files or the CI. v8 engine Issues and PRs related to the V8 dependency. labels May 14, 2018

ofrobots mentioned this pull request May 14, 2018
100% CPU caused by thread spike (in Fibers, Meteor) #20083
Closed

ofrobots force-pushed the backport-v8-5338 branch from a46a732 to 183d263Compare May 14, 2018 20:18

bnoordhuis approved these changes May 15, 2018
View reviewed changes

BridgeAR added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label May 15, 2018

jasnell approved these changes May 15, 2018
View reviewed changes

ofrobots added v6.x labels May 16, 2018

ofrobots closed this May 17, 2018

ofrobots deleted the backport-v8-5338 branch May 17, 2018 18:25

richardlau added lts-watch-v6.x labels May 21, 2018

addaleax mentioned this pull request May 22, 2018
v10.2.0 proposal #20724
Merged

MylesBorins added backport-requested-v8.x and removed lts-watch-v8.x labels Jun 25, 2018

ofrobots mentioned this pull request Jun 25, 2018
[8.x] deps: V8: backport b49206d from upstream #21529
Merged
2 tasks

MylesBorins mentioned this pull request Jul 9, 2018
v8.12.0 proposal #21593
Merged

veered mentioned this pull request Jul 20, 2018
Update Node to version 8.12.0 (prerelease). meteor/meteor#10090
Closed

jimrandomh mentioned this pull request Jul 31, 2018
[WIP] Comments server-side CPU usage ForumMagnum/ForumMagnum#765
Merged

Navigation Menu

Uh oh!

Uh oh!

deps: V8: cherry-pick b49206d fom upstream - #20727

deps: V8: cherry-pick b49206d fom upstream#20727
ofrobots wants to merge 1 commit into
nodejs:masterfrom
ofrobots:backport-v8-5338

ofrobots commented May 14, 2018•
edited
Loading

Uh oh!

bnoordhuis left a comment

Uh oh!

ofrobots commented May 17, 2018

Uh oh!

ofrobots commented May 17, 2018

Uh oh!

KoenLav commented May 21, 2018

Uh oh!

ofrobots commented May 21, 2018

Uh oh!

veered commented Jun 22, 2018

Uh oh!

ofrobots commented Jun 22, 2018

Uh oh!

MylesBorins commented Jun 25, 2018

Uh oh!

ofrobots commented Jun 25, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

Uh oh!

Uh oh!

Conversation

ofrobots commented May 14, 2018• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Checklist

Uh oh!

bnoordhuis left a comment

Choose a reason for hiding this comment

Uh oh!

ofrobots commented May 17, 2018

Uh oh!

ofrobots commented May 17, 2018

Uh oh!

KoenLav commented May 21, 2018

Uh oh!

ofrobots commented May 21, 2018

Uh oh!

veered commented Jun 22, 2018

Uh oh!

ofrobots commented Jun 22, 2018

Uh oh!

MylesBorins commented Jun 25, 2018

Uh oh!

ofrobots commented Jun 25, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

ofrobots commented May 14, 2018•
edited
Loading