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

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=f387764870a87c680d95c3dfeea130d7f9a09ec548c508cf1b59fbdfc8d46a17


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

Android Builder

Original CL has been reverted, but for a different reason. Thus this bug is good to fix for the reland.

I'm not sure how feasible it is to avoid adding the new SI, although I could certainly be wrong. AFAIK, it comes from the NDK itself, and not the Chromium changes that were necessary to make it compatible with the newer NDK. Andrew, what's your opinion on modifying the NDK code to remove the SI, if it's even possible?

From running supersize diff on the ndk commit:

Static Initializers Diff:
Index | Running Total | Section@Address | Δ PSS (Δ size_without_padding) | Path
------------------------------------------------------------
+ 0)        384 (101.1%) t@0x30fcc0   384 (0->372)       v8/src/parsing/token.cc
               startup
~ 1)        380 (100.0%) t@0x318768   -4 (52->48)        third_party/android_tools/ndk/sources/cxx-stl/llvm-libc++/libs/armeabi-v7a/libc++_static.a/iostream.o
               startup


Looks like the new one is actually from v8. Not sure why this changes with the ndk though. Also - the file only has primitives:
https://cs.chromium.org/chromium/src/v8/src/parsing/token.cc?q=parsing/token.cc

I'd guess we should just let this slide for now. It's not like we're at 0 SIs already, and there's nothing here that looks too harmful. Eventually someone might take on the initiative to get us to 0 SIs, but until then we're just operating at best-effort.