Platform Architecture Team snippet

93 views
Skip to first unread message

Kentaro Hara

unread,
Apr 24, 2017, 10:06:02 AM4/24/17
to blink-dev, platform-architecture-dev
Hi

- We finalized Q2 OKRs.
- I wrote a roadmap of the arch team.

Memory:

(ericrk, keishi) Achieved 50+ MB of reductions from CC. This is really amazing! keishi@ investigated memory usages of long-running apps and identified that we should proactively drop CC's image cache on page navigation (because the cache will rarely be reused after the navigation). ericrk@ implemented that change and achieved the 50+ MB memory reductions (200+ MB in some case) on a lot of System Health benchmarks!!

(tasak) Confirmed that Purge+Throttle is consistently reducing a significant amount of memory in a real world. According to UMAs, Purge+Throttle is reducing 17 MB per background tab at 50% tile (83 MB => 66 MB) and 43 MB at 75% tile (168 MB => 125 MB). This indicates that Purge+Throttle reduces 20 - 25% of background renderer's memory. Yay!

(tasak) Collecting more UMAs to figure out how to make the Purge+Throttle more aggressive. Also tasak@ is investigating how much memory we can purge if we accept some regression on the tab switching cost. ("Shallow purge" = purge as much memory as possible without regressing performance; "Deep purge" = purge as much memory as possible without breaking correctness.)

(bashi, haraken) Writing design docs to figure out the Memory Coordinator roadmap and the v0 shipping plan -- to get everyone on the same page.

(keishi, tasak) Investigated many "renderer is consuming 1+ GB memory" bugs and fixed them.

(keishi) Investigated and fixed many Oilpan crashes. (For some reason Oilpan-related crashes have been increasing recently.)

(keishi) Investigated memory usages of PWA. There are two action items: 1) investigate if we can reduce memory from a V8 isolate for a ServiceWorker thread, 2) consider ways to release temporary buffers of SW's fetched resources.

(panicker) Sent an intent-to-implement for the device RAM API and the memory pressure API. This is going to be a game changer, which enables web developers to optimize their websites for low-end devices & high memory pressure scenarios.

(hajimehoshi) Exposing base::SharedMemory to memory-infra. This work is getting more important to implement coherent memory UMAs (because we need to account for the shared memory correctly). The hard part is to properly attribute the shared memory to a right process without double-counting.

(ojan, panicker, miguelg, mariakhomenko, haraken etc) Brainstormed various ideas to reduce memory from low-end devices in short term.

Bindings:

(haraken, hpayer, mlippautz, jochen) Started brainstorming how to design and implement a unified GC (V8 & Oilpan). This is going to be awesome! At the very least, the mandatory requirement is that Oilpan should support an incremental marking. Discussing how to implement it.

(haraken, hpayer, mlippautz, jochen) Discussed the remaining action items for the wrapper tracing.

(jbroman, adithyas, haraken) We have decided to export V8's RuntimeCallStats to Blink (mainly the binding layer) to analyze and optimize Blink's performance using the same framework as V8. The nice thing of RuntimeCallStats is that it enables us to break down performance of real-world benchmarks (instead of micro-benchmarks) and keep track of the performance improvement/regression on the performance dashboard. WAT will be taking more ownership of the binding performance work.

(rakuco) Unifying all JS => C++ value conversions in the binding layer to NativeValueTraits. This removed a lot of hacky code!

(rakuco) Fixed a bunch of interop bugs in the binding layer. Made the IDL sequence conversion more spec-compliant, made an iterator behavior more spec-compliant etc.

(binji) Per the spec, most Web APIs do not accept shared array buffers. To force the restriction and make Blink's behavior more spec-compliant, binji@ introduced an [AllowShared] IDL extended attribute. Also binji@ introduced NotShared<> to avoid developers from passing shared array buffers to places where they should not be passed.

(adithyas) Cleaning up the binding layer by removing dependencies to core/ from low-level abstraction classes (e.g., ScriptState, WrapperTypeInfo, DOMWrapperMap etc).

(jl) Wrote a design doc to implement 'entry realms'.

(yukishiino) Removing ToV8(Window*). Fixed a couple of cross-origin access bugs.

(peria) Implementing the V8 context snapshotting. Now only a couple of layout tests are failing.

Onion Soup:

(slangley) Wrote a design doc to remove the web/ layer. Started moving code from web/ to core/ or modules/.

(yutak) Finally finished moving wtf/ to platform/wtf/! This enables us to remove a bunch of hacks that have existed to bypass the disallowed dependency from wtf/ to platform/. yutak@ added an amazing README.md to platform/wtf/.

(joelhockey) Removing the FrameViewBase class hierarchy. There're a lot of complexity but joel is making great progress.

(sashab) Removing unnecessary nullptr checks for WebFrameClient*, WebLocalFrame* etc.

(dglazkov, haraken) Writing a design doc for Onion Soup 2.0. Writing a design doc for Web Agents.

Scheduling:

(nhiroki) Moved tasks on worker threads from the default task scheduler to the per-frame scheduler. Cleaning up primitives to post tasks to the main thread / worker threads.

(haraken, jochen) Brainstormed how to implement green threads in Blink.


--
Kentaro Hara, Tokyo, Japan

Walter

unread,
May 4, 2017, 5:21:31 PM5/4/17
to blink-dev, platform-arc...@chromium.org, Xida Chen, Philip Rogers
Hi there, can you resend the correct link to slangley@ design doc on removing the web/ layer? It looks like it's accidentally a link to the 'entry realms' doc.

Joel Hockey

unread,
May 4, 2017, 6:21:15 PM5/4/17
to Walter, blink-dev, platform-architecture-dev, Xida Chen, Philip Rogers
https://docs.google.com/document/d/1w1EAnl4WRjl0Utf4bKcgCPOLmmGVugj9kGOGCpFnQok/edit
> --
> You received this message because you are subscribed to the Google Groups
> "platform-architecture-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to platform-architect...@chromium.org.
> To post to this group, send email to platform-arc...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/479e20ef-7686-4080-8a14-6b69b9883536%40chromium.org.
Reply all
Reply to author
Forward
0 new messages