Hi
Oilpan:
(haraken, sigbjornf, keishi, yutak) Resolved a bunch of issues Oilpan has introduced. We made great progress:
[Stability]
- sigbjornf@ fixed a bunch of crash reports.
- keishi@ fixed failures of inspector tests.
- As far as I look at the top 150 crash reports from 50.0.2638.0 (Shipped to Win/Mac Dev on Feb 2), all Oilpan-related crashes are already filed and taken care of. None of them is a serious crasher. The stability looks extremely good.
[Memory]
- yutak@ investigated regressions in memory.memory_health_plan and identified that the regressions are caused by the fact that Oilpan does not aggressively discard system pages in free lists. haraken@ created a
CL to make Oilpan discard system pages in free lists on low-RAM devices.
[Performance]
- haraken@ investigated regressions in V8 GC metrics and identified that the regressions are caused by the fact that Oilpan's GC can be triggered during prologues/epilogues of V8 GCs, making the V8 GC metrics worse. haraken@ is working on factoring out Oilpan's GC from prologues/epilogues of V8 GCs (
CL,
CL,
CL).
- keishi@ investigated other performance regressions (e.g., frame_times) and noticed that most of the regressions Oilpan has introduced were already recovered (for some reason we don't know; we are lucky anyway :-). The remaining regressions are page_cycler.morejs and a couple of micro benchmarks.
- keishi@ is investigating slowness of layout tests on Debug builds.
TRIM-platform:
(tasak) Experimenting with purging as many things as possible in the renderer to see how much memory we can save from the renderer. georgesak@ improved the TabManager so that memory pressure notifications are delivered to the renderers, so we can use the notifications to trigger the purging. Our goal is to make all sub-systems in the renderer be aware of the pressure notifications and take action when requested by the TabManager.
(bashi) Investigating how to reduce the peak memory consumption on low-RAM devices. bashi@ noticed that redundant copying from SharedBuffer::m_segments to SharedBuffer::m_buffer may contribute to the peak memory increase. bashi@ is investigating how much memory we can save by getting rid of the redundant copying. (Either way, it's worth cleaning up the memory management of SharedBuffers -- working with the loading team.)
(hajimehoshi) Supporting the heap profiler in Oilpan. Did some refactoring in preparation for that.
(haraken) Wrote a document to summarize the current status of various memory-reduction teams in Chromium. (I'll publish the document once it's ready.)
Onion Soup:
(yukishiino) Moving battery_status from content/renderer/ to Blink's platform/. There are a couple of design issues such as whether we should allow using Mojo in modules/, how to write tests for Mojo services (in layout tests in JS or in unittests in C++).
Discussing the design.
(haraken) I've learned what the "Onion Soup" means.
An onion has a lot of layers:

By (reasonably) breaking the unnecessary layers into a soup, the world becomes a better place to live:

V8 bindings:
(haraken) Removed sampling tracing macros from the V8 binding layer (
CL). (Now that V8 supports tracing, if we really want to have tracing macros in the binding layer, we should add the macros to V8 instead of adding them to each C++ callback for DOM attribute/method/constant.) This reduced the binary size by 600 KB.
(yukishiino, verwaest) Working on a complicated behavioral bug around SetAccessor/SetNativeDataProperty and [Replaceable] DOM attributes.
(peria, haraken) Oilpan knows a good estimation of the size of DOM objects indirectly retained by V8 wrappers (e.g., size of NodeLists, size of Nodes etc). peria@ is making Oilpan report the size to V8. This enables us to remove hand-written AdjustAmountOfExternalAllocatedMemory from the code base.
(haraken) Moving hasPendingActivity from ActiveDOMObject to ScriptWrappable. Now the
CL passes all tests.
(haraken) Considering how to deprecate v8::Object::CreationContext (requested by the V8 team).
--
Kentaro Hara, Tokyo, Japan
--
Kentaro Hara, Tokyo, Japan