jochen@ it seems hablich@ is OOO; can you find someone to look into this.

Still can't save a trace. Although the CallOnBackgroundThread is blocked on the 
v8.parseOnBackground

Start	
6,364.499 ms
Wall Duration	
27,154.727 ms
CPU Duration	
82.195 ms

But look at the difference between Wall time and CPU Duration. Something seems like it is getting not run correctly.

Here is one trace

Deleted: trace_ibm.json.gz 1.8 MB

trace_ibm.json.gz 1.8 MB Download

Here is an all categories trace

Deleted: trace_all_categories.json.gz 8.6 MB

trace_all_categories.json.gz 8.6 MB Download

(gdb) info threads
  Id   Target Id         Frame 
  16   Thread 0x7f95d2ae2700 (LWP 15927) "TaskSchedulerSe" 0x00007f95df730a13 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81
  15   Thread 0x7f95d22e1700 (LWP 15928) "Chrome_ChildIOT" 0x00007f95df730a13 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81
  14   Thread 0x7f95d1ae0700 (LWP 15929) "GpuMemoryThread" pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  13   Thread 0x7f95d12df700 (LWP 15930) "Compositor" pthread_cond_timedwait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
  12   Thread 0x7f95d0ade700 (LWP 15931) "Renderer::FILE" pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  11   Thread 0x7f95d02dd700 (LWP 15932) "CompositorTileW" pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  10   Thread 0x7f95cfadc700 (LWP 15933) "CompositorTileW" pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  9    Thread 0x7f95cf2db700 (LWP 15934) "CompositorTileW" pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  8    Thread 0x7f95ceada700 (LWP 15935) "CompositorTileW" pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  7    Thread 0x7f95ce2d9700 (LWP 15936) "CompositorTileW" pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  6    Thread 0x7f95cd697700 (LWP 15937) "WorkerPool/1593" 0x00007f95e34a3819 in---Type <return> to continue, or q <return> to quit--- 
 v8::internal::compiler::BasicBlock::GetCommonDominator(v8::internal::compiler::BasicBlock*, v8::internal::compiler::BasicBlock*) ()
   from /work/chromium_ensemble/src/out/Release/./libv8.so
  5    Thread 0x7f95cc683700 (LWP 15939) "ScriptStreamerT" pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  4    Thread 0x7f95cbe82700 (LWP 15940) "WorkerPool/1594" pthread_cond_timedwait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
  3    Thread 0x7f95cb681700 (LWP 15941) "WorkerPool/1594" pthread_cond_timedwait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
  2    Thread 0x7f95cae80700 (LWP 15942) "WorkerPool/1594" pthread_cond_timedwait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238
* 1    Thread 0x7f95d5958a00 (LWP 15926) "chrome" pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185


thread 1:
#0  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f95e33a911b in v8::internal::OptimizingCompileDispatcher::Flush() ()
   from /work/chromium_ensemble/src/out/Release/./libv8.so
#2  0x00007f95e360ca38 in v8::internal::Heap::NotifyContextDisposed(bool) ()
   from /work/chromium_ensemble/src/out/Release/./libv8.so
#3  0x00007f95db04e6eb in blink::V8GCForContextDispose::notifyContextDisposed(bool) () from /work/chromium_ensemble/src/out/Release/./libblink_core.so
#4  0x00007f95db060ee9 in blink::WindowProxy::disposeContext(blink::WindowProxy::GlobalDetachmentBehavior) ()
   from /work/chromium_ensemble/src/out/Release/./libblink_core.so
#5  0x00007f95db019510 in blink::LocalWindowProxy::disposeContext(blink::WindowProxy::GlobalDetachmentBehavior) ()
   from /work/chromium_ensemble/src/out/Release/./libblink_core.so
#6  0x00007f95db061660 in blink::WindowProxyManagerBase::clearForNavigation()
    () from /work/chromium_ensemble/src/out/Release/./libblink_core.so
#7  0x00007f95db01f60c in blink::ScriptController::clearWindowProxy() ()
   from /work/chromium_ensemble/src/out/Release/./libblink_core.so
#8  0x00007f95db3f9e6b in blink::LocalFrame::setDOMWindow(blink::LocalDOMWindow*) () from /work/chromium_ensemble/src/out/Release/./libblink_core.so
#9  0x00007f95db768e04 in blink::DocumentLoader::createWriterFor(blink::DocumentInit const&, WTF::AtomicString const&, WTF::AtomicString const&, bool, blink::ParserSynchronizationPolicy, blink::KURL const&) ()


thread 6:
#0  0x00007f95e34a3819 in v8::internal::compiler::BasicBlock::GetCommonDominator(v8::internal::compiler::BasicBlock*, v8::internal::compiler::BasicBlock*) ()
   from /work/chromium_ensemble/src/out/Release/./libv8.so
#1  0x00007f95e34aadbb in v8::internal::compiler::ScheduleLateNodeVisitor::VisitNode(v8::internal::compiler::Node*) ()
   from /work/chromium_ensemble/src/out/Release/./libv8.so
#2  0x00007f95e34aacd7 in v8::internal::compiler::ScheduleLateNodeVisitor::ProcessQueue(v8::internal::compiler::Node*) ()
   from /work/chromium_ensemble/src/out/Release/./libv8.so
#3  0x00007f95e34a6fec in v8::internal::compiler::Scheduler::ScheduleLate() ()
   from /work/chromium_ensemble/src/out/Release/./libv8.so
#4  0x00007f95e34a5fd0 in v8::internal::compiler::Scheduler::ComputeSchedule(v8::internal::Zone*, v8::internal::compiler::Graph*, v8::base::Flags<v8::internal::compiler::Scheduler::Flag, int>) ()
   from /work/chromium_ensemble/src/out/Release/./libv8.so
#5  0x00007f95e348b3ce in void v8::internal::compiler::PipelineImpl::Run<v8::internal::compiler::ComputeSchedulePhase>() ()
   from /work/chromium_ensemble/src/out/Release/./libv8.so
#6  0x00007f95e3488635 in v8::internal::compiler::PipelineImpl::ScheduleAndSelectInstructions(v8::internal::compiler::Linkage*, bool) ()
   from /work/chromium_ensemble/src/out/Release/./libv8.so
#7  0x00007f95e34879e7 in v8::internal::compiler::PipelineImpl::OptimizeGraph(v8::internal::compiler::Linkage*) ()

thread 5 seems stuck on the SourceStream;

#0  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f95db029681 in blink::SourceStream::GetMoreData(unsigned char const**) () from /work/chromium_ensemble/src/out/Release/./libblink_core.so
#2  0x00007f95e379da37 in v8::internal::(anonymous namespace)::FindChunk(std::vector<v8::internal::(anonymous namespace)::Chunk, std::allocator<v8::internal::(anonymous namespace)::Chunk> >&, v8::ScriptCompiler::ExternalSourceStream*, unsigned long, v8::internal::RuntimeCallStats*) ()
   from /work/chromium_ensemble/src/out/Release/./libv8.so
#3  0x00007f95e379d6ee in v8::internal::OneByteExternalStreamingStream::FillBuffer(unsigned long) () from /work/chromium_ensemble/src/out/Release/./libv8.so
#4  0x00007f95e379cc95 in v8::internal::BufferedUtf16CharacterStream::ReadBlock() () from /work/chromium_ensemble/src/out/Release/./libv8.so
#5  0x00007f95e37a05a1 in v8::internal::Scanner::ScanString() ()
   from /work/chromium_ensemble/src/out/Release/./libv8.so
#6  0x00007f95e379f330 in v8::internal::Scanner::Scan() ()
   from /work/chromium_ensemble/src/out/Release/./libv8.so
#7  0x00007f95e379eb38 in v8::internal::Scanner::Next() ()
   from /work/chromium_ensemble/src/out/Release/./libv8.so
#8  0x00007f95e376ce9e in v8::internal::ParserBase<v8::internal::Parser>::ParseObjectLiteral(bool*) () from /work/chromium_ensemble/src/out/Release/./libv8.so
#9  0x00007f95e3775088 in v8::internal::ParserBase<v8::internal::Parser>::ParseMemberExpression(bool*, bool*) ()

thx for the analysis. I think there are two issues: issue 642532 about the fact that GC can block the main thread when it wants to stop background threads, and another (new) issue that turbofan takes so long to optimize.

the parser thread is a red herring, it just waits for data from the main thread, but the main thread isn't blocked due to it.

Assigning this to mvstanton@ to triage the TF issue

At least in the "all categories" trace we're waiting 20 seconds on https://static.hotjar.com/c/hotjar-42920.js?sv=5 (see scriptstreamer thread, you'll see that CPU time is 65ms, which is how long the parser took for the the data it had; and it's waiting the remainder of the time for the network). If you just try to curl this file, you see it downloads the first part fairly quickly, but then hangs for a long time. Perhaps something even times out after that time?

 Issue 686213  has been merged into this issue.

Also the blocked main thread is spending all its time in Callback; using basically no CPU for the entire duration.

The scriptstreamer thread actually starts downloading the file before the main thread gets blocked, but it does block as long as the scriptstreamer thread is waiting for input.

FWIW I bisect this to  https://chromium.googlesource.com/chromium/src/+log/1b37cd6a32a0205f2bc61dfc4b19609e2db6761a..db6cc02a443dbd2b485875583204d7c813f6335e

which is v8 roll:

https://chromium.googlesource.com/v8/v8/+log/44fc3b87..174da467

which is the ignition roll, as previously determined.

I guess the ScriptStreamer is just confusing; it seems like the main thread is actually hanging on the WorkerThread doing CallOnBackgroundThread, which is probably just background compilation. (Called with "v8::Platform::kShortRunningTask" if it's coming from optimizing-compile-dispatcher.cc :))

The CPU tines all seemed small to be relative to the wall times in the trace. Which made me believe this is some type of mutex timeout. 

Actually with --noconcurrent-recompilation you can see that there's a background compile job (I assume TurboFan) that takes at least over 22seconds. With --noconcurrent-recompilation we block on that background job because of a side effect in context disposal notification (which jochen@ found out in the stack in https://bugs.chromium.org/p/chromium/issues/detail?id=686153#c8).

There seem to be many background recompilation jobs that take multiple seconds, but especially the following functions are very expensive on Canary:

[optimizing 0x3768fd412e1 <JS Function hj.md5 (SharedFunctionInfo 0x3768fd5e1e1)> - took 2.800, 8.193, 0.524 ms]
[optimizing 0x761784ab6d1 <JS Function m (SharedFunctionInfo 0x3768fd5db61)> - took 3.347, 12.237, 0.960 ms]

It seems like the "m" function doesn't affect stable yet since at least in one run we tried it went through crankshaft.

OS-Android at least.

Our test team sees the issue there and found the following info, looks like it matches.

Range: https://chromium.googlesource.com/chromium/src/+log/56.0.2905.0..56.0.2906.0?pretty=fuller&n=10000
CL: https://chromium.googlesource.com/chromium/src/+/db6cc02a443dbd2b485875583204d7c813f6335e

Applying OS=Linux per bug description and OS=Mac as Anantha is able to repro on Mac.

Mano confirmed, it repros on Windows too.

V8 folks, we need to cut our stable build on Monday, so we'll need fixes landed on the M56 V8 branch by then - preferably with the minimal amount of risk since we won't have any time to bake them.

Tested on Samsung J7/LMY48B ,Pixel/NDE64G
Steps:
1. Launch the app
2. Open new tab and load the url -https://www.ibm.com/watson/developercloud/doc/speech-to-text/
3. Zoom-in/out the page and scroll

amineer@ I don't know whether we can realistically do that, sorry :/

Some more analysis, it seems like the majority of time is spend in AllocateGeneralRegistersPhase<LinearScanAllocator>. Add mtrofin@ - maybe it's related to https://bugs.chromium.org/p/v8/issues/detail?id=5644 ?

The script https://tags.tiqcdn.com/utag/ibm/main/prod/utag.js defines a function, loadrules, which is a large switch statement. This gets compiled with TF, and results in an instruction sequence of over 170K instructions and over 215K live ranges.

The register allocator spends, on that, a bit under 5 seconds (on a MBPro). Which, given the scale of this, and the supralinear nature of the register allocator, is not an unexpected result. Overall, we spend over 12s compiling.

I think we need to understand why the function becomes so large in the first place.

I suspect that in the past, we just didn't attempt to optimize this function, as it contains code that is not supported by crankshaft. Now that TF can optimize everything, we might run into situations of large functions that all of the sudden get optimized blocking the renderer for a long time

A bit of what loadrules does:

  utag.loader.loadrules = function(_pd, _pc) {
        var d = _pd || utag.data;
        var c = _pc || utag.cond;
        for (var l in utag.loader.GV(c)) {
            switch (l) {
            case '1000':
                try {
                    c[1000] |= (d['dom.url'].toString().toLowerCase() == 'https://www.ibm.com/ibmid/basic_register/register.html?watsonanalytics=true&cm_mmc=WAMicrositeOrganic--C24803SW'.toLowerCase())
                } catch (e) {
                    utag.DB(e)
                }
                ;break;
            case '1002':
                try {
                    c[1002] |= (d['dom.url'].toString().toLowerCase() == 'https://www.ibm.com/ibmid/basic_register/register.html'.toLowerCase())
                } catch (e) {
                    utag.DB(e)
                }
                ;break;
            case '1003':
                try {
                    c[1003] |= (d['dom.url'].toString().toLowerCase() == 'https://www.ibm.com/ibmid/basic_register/register.html?watsonanalytics=true'.toLowerCase() && d['country_code'] != 'CN')
                } catch (e) {
                    utag.DB(e)
                }

... and so on up to 2701, and then restarts from 678 and goes to 998. So that's, what, about 2022 or so (hoping there were no holes in that numbering) elements.

It looks like an initialization function that's populating an array. The value of optimizing this is probably very, very low. 

Do we / should we have heuristics that would first run the interpreter, especially for textually large functions, maybe? We could still background compile this thing, if we wanted to. 

that's actually what we do, but then GC kicks in and flushes the bg compile jobs which blocks the entire renderer.

I see - is that considered a problem, and do we have an issue for it? Should this here be merged with that, then?

issue 642532 and https://codereview.chromium.org/2658313002

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/22858cb0d494c936cd85c1d1f0cebfc70e72fe08

commit 22858cb0d494c936cd85c1d1f0cebfc70e72fe08
Author: jochen <jochen@chromium.org>
Date: Mon Jan 30 02:27:17 2017

Only flush not yet started and finished compile jobs from gc

We shouldn't block during GC for arbitrarily long intervals.

BUG= chromium:686153 ,chromium:642532
R=verwaest@chromium.org,hpayer@chromium.org

Review-Url: https://codereview.chromium.org/2658313002
Cr-Commit-Position: refs/heads/master@{#42761}

[modify] https://crrev.com/22858cb0d494c936cd85c1d1f0cebfc70e72fe08/src/compiler-dispatcher/optimizing-compile-dispatcher.cc
[modify] https://crrev.com/22858cb0d494c936cd85c1d1f0cebfc70e72fe08/src/compiler-dispatcher/optimizing-compile-dispatcher.h
[modify] https://crrev.com/22858cb0d494c936cd85c1d1f0cebfc70e72fe08/src/debug/debug.cc
[modify] https://crrev.com/22858cb0d494c936cd85c1d1f0cebfc70e72fe08/src/heap/heap.cc

Thanks for the fix Jochen. Is there more to do besides merge this to the branch?

we still need to ensure that we don't block for half a minute compiling. On this site, we happen to use the background compiler, but we may as well do that on the foreground on other sites

The first part of the fix in #33 is not yet deployed to Canary. The second part might land tomorrow which means we probably will have Canary coverage on Wednesday. 

govind@ is this still from pre-stable?

Is there anything we can revert to address this instead?  I'm guessing no but have to ask.

I doubt it.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/475b455b6f67cc825d02641499ab4558f83d6d9a

commit 475b455b6f67cc825d02641499ab4558f83d6d9a
Author: mvstanton <mvstanton@chromium.org>
Date: Mon Jan 30 15:28:23 2017

[Turbofan] don't optimize from bytecode > 250K in size.

Compiles simply take too long, and such functions are liable to deopt
quickly.

BUG= chromium:686153 

Review-Url: https://codereview.chromium.org/2667573002
Cr-Commit-Position: refs/heads/master@{#42779}

[modify] https://crrev.com/475b455b6f67cc825d02641499ab4558f83d6d9a/src/runtime-profiler.cc

Hi, we'll get canary coverage on this fix and you can take it on your wednesday build...

Is there any reason to think this wouldn't affect Chrome OS?   Adding the tag to keep them in the loop.

Re #36, yes this bug was reported on pre-stable version 56.0.2924.76.

It seems that as all patches have been landed, we should have canary coverage by tomorrow, Wednesday at the latest - correct?

If so, we need to arrange for all patches to be merged to M56 branch by Tuesday at 5 PM PT so that the fixes are picked up in our daily M56 build.  Since 5 PM PT is 2 AM in Munich, and I'm unsure of team availability outside of normal business hours, can we please merge the fixes to the M56 branch tomorrow?  That way they can be picked up in tomorrow night's build, we can qualify it Tuesday night, and then ship it Wednesday (assuming canary data comes back OK).

Yes, certainly I'll work to get them in the branch today (tuesday in germany)

Seems okay in Canary.

Tested in chrome # 56.0.2924.76 and 56.0.2924.84 on Ubuntu 14.04, Mac 10.12.2 & win 10.0 and not able to reproduce the issue.Please find the screen cast url your reference.
https://drive.google.com/a/google.com/file/d/0Bx0w4BGmWEIqX0FlUnBYaTIwemM/view?usp=sharing

@ dtapuska:Could you please let me know if i have missed anything and if possible, provide us with a sample steps of the issue which would help us to triage the issue further.

Thanks in Advance.

The video you shared doesn't look like you are reproduction it. The first URI it reproduced on by loading the URI in an already open tab. Ie. Load the URI and then refresh it causes the issue. 

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/26d8e8c75f401b4ad391cf3e3996e0e087d3bb10

commit 26d8e8c75f401b4ad391cf3e3996e0e087d3bb10
Author: Mike Stanton <ripsawridge@gmail.com>
Date: Tue Jan 31 14:26:05 2017

Merged: [Turbofan] don't optimize from bytecode > 250K in size.

Revision: 475b455b

BUG= chromium:686153 
LOG=N
NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true
R=danno@chromium.org

Review-Url: https://codereview.chromium.org/2661133003 .
Cr-Commit-Position: refs/branch-heads/5.6@{#100}
Cr-Branched-From: bdd3886218dfe76e8560eb8a18401942452ae859-refs/heads/5.6.326@{#1}
Cr-Branched-From: 879f6599eee6e1dfcbe9a24bf688b261c03e9558-refs/heads/master@{#41014}

[modify] https://crrev.com/26d8e8c75f401b4ad391cf3e3996e0e087d3bb10/src/runtime-profiler.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/b36657e21c261bd3ae8995233a0d1b4d49a02afb

commit b36657e21c261bd3ae8995233a0d1b4d49a02afb
Author: Mike Stanton <ripsawridge@gmail.com>
Date: Tue Jan 31 14:41:53 2017

Merged: Only flush not yet started and finished compile jobs from gc

Revision: 22858cb0d494

BUG=chromium:642532, chromium:686153 
LOG=N
NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true
R=danno@chromium.org

Review-Url: https://codereview.chromium.org/2669603002 .
Cr-Commit-Position: refs/branch-heads/5.6@{#102}
Cr-Branched-From: bdd3886218dfe76e8560eb8a18401942452ae859-refs/heads/5.6.326@{#1}
Cr-Branched-From: 879f6599eee6e1dfcbe9a24bf688b261c03e9558-refs/heads/master@{#41014}

[modify] https://crrev.com/b36657e21c261bd3ae8995233a0d1b4d49a02afb/src/compiler-dispatcher/optimizing-compile-dispatcher.cc
[modify] https://crrev.com/b36657e21c261bd3ae8995233a0d1b4d49a02afb/src/compiler-dispatcher/optimizing-compile-dispatcher.h
[modify] https://crrev.com/b36657e21c261bd3ae8995233a0d1b4d49a02afb/src/debug/debug.cc
[modify] https://crrev.com/b36657e21c261bd3ae8995233a0d1b4d49a02afb/src/heap/heap.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/84db03ddede82d777a5e9d0fde185758b6991aa4

commit 84db03ddede82d777a5e9d0fde185758b6991aa4
Author: Mike Stanton <ripsawridge@gmail.com>
Date: Tue Jan 31 14:45:09 2017

Merged: Only flush not yet started and finished compile jobs from gc

Revision: 22858cb0d494

BUG=chromium:642532, chromium:686153 
LOG=N
NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true
R=danno@chromium.org

Review-Url: https://codereview.chromium.org/2660403003 .
Cr-Commit-Position: refs/branch-heads/5.7@{#74}
Cr-Branched-From: 975e9a320b6eaf9f12280c35df98e013beb8f041-refs/heads/5.7.492@{#1}
Cr-Branched-From: 8d76f0e3465a84bbf0bceab114900fbe75844e1f-refs/heads/master@{#42426}

[modify] https://crrev.com/84db03ddede82d777a5e9d0fde185758b6991aa4/src/compiler-dispatcher/optimizing-compile-dispatcher.cc
[modify] https://crrev.com/84db03ddede82d777a5e9d0fde185758b6991aa4/src/compiler-dispatcher/optimizing-compile-dispatcher.h
[modify] https://crrev.com/84db03ddede82d777a5e9d0fde185758b6991aa4/src/debug/debug.cc
[modify] https://crrev.com/84db03ddede82d777a5e9d0fde185758b6991aa4/src/heap/heap.cc

Fixes merged to 5.6 and 5.7

Not reproduce the issue on CrOS 9000.76.0/Chrome 56.0.2924.79 - Candy, Daisy.

Check the issue on the following sites and scrolling is smooth on the pages :
https://www.ibm.com/watson/developercloud/doc/speech-to-text/
https://productforums.google.com/forum/#!forum/chrome
http://stardewvalleywiki.com/
https://www.reddit.com/r/Battlefield/

Verified issue on Windows-10, Ubuntu 14.04 and Mac OS 10.12.2 using chrome latest Stable M56-56.0.2994.87 and M57- 57.0.2987.20 by following steps mentioned in the original comment. Observed that for above sites scrolling is smooth as expected.
I am unable to upload screen cast file.So providing the path for reference.

https://drive.google.com/a/google.com/file/d/0Bx0w4BGmWEIqa3FPaGJPeE10dkE/view?usp=sharing
https://drive.google.com/a/google.com/file/d/0Bx0w4BGmWEIqSUItOWQtVUg1ZGM/view?usp=sharing

Thank you!

Android: Verified on M56-56.0.2994.87 and 57.0.2987.20

Checked the below sites, scrolling is smooth as per expected behavior 

https://www.ibm.com/watson/developercloud/doc/speech-to-text/
https://productforums.google.com/forum/#!forum/chrome
http://stardewvalleywiki.com/
https://www.reddit.com/r/Battlefield/