All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=736097

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgjvHmpQgM


Bot(s) for this bug's original alert(s):

Android Builder

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8976051451989763344

Partial symbol diff (run "tools/binary_size/diagnose_bloat.py baf954759bd36926bc2136a505d302a5d0fddd0a -v --subrepo v8" to repro locally):

Index | Running Total | Section@Address | Δ PSS (Δ size_without_padding) | Path
------------------------------------------------------------
~ 0)       7088 (51.0%) t@0x1105bf8  +7088 (2428->9516) v8/src/heap/mark-compact.cc
               v8::internal::HeapVisitor::Visit
~ 1)       7550 (54.4%) t@0x10fe368  +462 (266->728)    v8/src/heap/mark-compact.cc
               v8::internal::HeapVisitor::VisitJSArrayBuffer
~ 2)       7862 (56.6%) t@0x10fdd2c  +312 (188->500)    v8/src/heap/mark-compact.cc
               v8::internal::HeapVisitor::VisitCode
~ 3)       8158 (58.7%) t@0x10fe640  +296 (68->364)     v8/src/heap/mark-compact.cc
               v8::internal::YoungGenerationMarkingVisitor::VisitJSFunction
~ 4)       8452 (60.9%) t@0x10fdbdc  +294 (42->336)     v8/src/heap/mark-compact.cc
               v8::internal::HeapVisitor::VisitCell
~ 5)       8744 (63.0%) t@0x10fd9c0  +292 (44->336)     v8/src/heap/mark-compact.cc
               v8::internal::HeapVisitor::VisitAllocationSite
~ 6)       9036 (65.1%) t@0x10fe86c  +292 (236->528)    v8/src/heap/mark-compact.cc
               v8::internal::HeapVisitor::VisitJSRegExp
~ 7)       9328 (67.2%) t@0x10fed1c  +292 (44->336)     v8/src/heap/mark-compact.cc
               v8::internal::HeapVisitor::VisitPropertyCell
~ 8)       9620 (69.3%) t@0x10ff040  +292 (44->336)     v8/src/heap/mark-compact.cc
               v8::internal::HeapVisitor::VisitSymbol
~ 9)       9912 (71.4%) t@0x10ff2e0  +292 (240->532)    v8/src/heap/mark-compact.cc
               v8::internal::HeapVisitor::VisitTransitionArray
~ 10)     10204 (73.5%) t@0x10ff4f4  +292 (44->336)     v8/src/heap/mark-compact.cc
               v8::internal::HeapVisitor::VisitWeakCell
~ 11)     10494 (75.6%) t@0x10fea7c  +290 (46->336)     v8/src/heap/mark-compact.cc
               v8::internal::HeapVisitor::VisitMap
~ 12)     10784 (77.6%) t@0x10febcc  +290 (46->336)     v8/src/heap/mark-compact.cc
               v8::internal::HeapVisitor::VisitOddball
~ 13)     11074 (79.7%) t@0x10ff190  +290 (46->336)     v8/src/heap/mark-compact.cc
               v8::internal::HeapVisitor::VisitThinString
- 14)     10784 (77.6%) t@0x0        -290 (290->0)      v8/src/heap/mark-compact.cc
               v8::internal::YoungGenerationMarkingTask::EmptyMarkingDeque
+ 15)     11056 (79.6%) t@0x10ffb24  +272 (0->272)      v8/src/heap/mark-compact.cc
               v8::internal::Code::BodyDescriptor::IterateBody
+ 16)     11300 (81.4%) t@0x10f4a28  +244 (0->244)      v8/src/heap/mark-compact.cc
               v8::internal::WorkStealingBag::~WorkStealingBag
+ 17)     11512 (82.9%) t@0x10ffa50  +212 (0->212)      v8/src/heap/mark-compact.cc
               v8::internal::WorkStealingBag::Push
+ 18)     11724 (84.4%) t@0x10f48fc  +212 (0->212)      v8/src/heap/mark-compact.cc
               v8::internal::WorkStealingBag::WorkStealingBag
- 19)     11540 (83.1%) t@0x0        -184 (184->0)      v8/src/heap/mark-compact.cc
               v8::internal::WorkStealingMarkingDeque::~WorkStealingMarkingDeque
~ 20)     11384 (82.0%) t@0x10f489c  -156 (252->96)     v8/src/heap/mark-compact.cc
               v8::internal::MinorMarkCompactCollector::MinorMarkCompactCollector
~ 21)     11538 (83.1%) t@0x10fd7bc  +154 (202->356)    v8/src/heap/mark-compact.cc
               v8::internal::YoungGenerationMarkingVisitor::VisitPointers
~ 22)     11690 (84.2%) t@0x10ff794  +152 (20->172)     v8/src/heap/mark-compact.cc
               v8::internal::HeapVisitor::VisitDataObject
~ 23)     11840 (85.3%) t@0x10ff644  +150 (186->336)    v8/src/heap/mark-compact.cc
               v8::internal::YoungGenerationMarkingVisitor::VisitNativeContext
~ 24)     11988 (86.3%) t@0x10fdb10  +148 (32->180)     v8/src/heap/mark-compact.cc
               v8::internal::HeapVisitor::VisitByteArray
~ 25)     12136 (87.4%) t@0x10fe070  +148 (40->188)     v8/src/heap/mark-compact.cc
               v8::internal::HeapVisitor::VisitFixedArray
~ 26)     12284 (88.5%) t@0x10fe12c  +148 (32->180)     v8/src/heap/mark-compact.cc
               v8::internal::HeapVisitor::VisitFixedDoubleArray
~ 27)     12432 (89.5%) t@0x10ff840  +148 (20->168)     v8/src/heap/mark-compact.cc
               v8::internal::HeapVisitor::VisitFreeSpace
~ 28)     12580 (90.6%) t@0x10fee6c  +148 (32->180)     v8/src/heap/mark-compact.cc
               v8::internal::HeapVisitor::VisitSeqOneByteString
~ 29)     12728 (91.6%) t@0x10fef20  +148 (32->180)     v8/src/heap/mark-compact.cc
               v8::internal::HeapVisitor::VisitSeqTwoByteString


mlippautz@ - This isn't a huge jump but it seems likely the increase was unintended/unknown. Is there anything we can do to reduce the impact of this change? 

Thanks. That is indeed a bit unexpected.

We introduced a new (better) data structure as our work queue here. The fast path definitely needs to be inlined but doesn't really contain any code that I could see resulting in this growth.

We also added 1 std::vector as a semi fast-path. Maybe push_back, back, and pop_back inlining resulted in that growth.

I will play a bit locally with the inlining here and see what I can do.

Yeah we've seen std::vector usage causing quite a bit of these jumps, thanks for looking into it!

If you want to use //tools/binary_size to see the symbols that are changing you can run "tools/binary_size/diagnose_bloat.py HEAD -v --subrepo v8" (assuming you commit your changes locally first and you aren't using a standalone v8 build). More instructions here:  https://chromium.googlesource.com/chromium/src/+/master/tools/binary_size/README.md.

I could indeed reduce the size again by having non-inlined paths for the operations that involve vectors. 

Will discuss this with colleagues and report back on whether we can afford this or not as the data structure will soon be used in another per critical component.

Sounds good :)

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

commit e9e2e1332854feb3add832d711f75e814372203a
Author: Michael Lippautz <mlippautz@chromium.org>
Date: Fri Jun 23 09:16:39 2017

[heap] Do not inline WorkStealingBag ops that involve vectors

Reduces binary size, see bug.

Bug:  chromium:736097 
Change-Id: I89b4b873accf2de85d5913a30fac53972d98e78d
Reviewed-on: https://chromium-review.googlesource.com/544984
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46160}
[modify] https://crrev.com/e9e2e1332854feb3add832d711f75e814372203a/src/heap/workstealing-bag.h

This should be fixed now. Thanks for checking back!

On the plus side, this confirmed that inlining works properly :)

It looks the the perf graph didn't show any changes for your fix (roll was point 481865 of https://chromeperf.appspot.com/report?sid=99caa6c5389f77e13b562afa5703ad8fc1dfd9784effeb8760626be0c71e498b&start_rev=481860&end_rev=481870) and I wasn't able to verify the size savings locally..

Just wanted to make sure we get the size savings for inlining, otherwise you might as well leave these non-inlined. Thanks for your patience.

We reshuffled the visitors quite a bit over the last few days. 

I cannot reproduce any actual difference anymore, i.e., even without NO_INLINE I get 0 bytes difference on HEAD.

We are not relying on inlining here so we will probably keep as is for now.