Intent to Ship: Out-of-process V8 proxy resolver.

[Anand K. Mistry]

Contact emails

ami...@chromium.org, sa...@chromium.org

Spec

Bug: https://code.google.com/p/chromium/issues/detail?id=11746

Launch bug for Chrome (sorry, googlers only): https://code.google.com/p/chromium/issues/detail?id=482790

Implementation proposal: https://drive.google.com/open?id=1n5hr4KJhZl2A4MicTfmyiHPdiKp7kmUoWXnRBN8SrZE

Summary

Moves the V8 proxy resolver from the browser process to a sandboxed utility process. The goal is to remove the ability to use V8 from the browser process and eliminate one possible attack surface.

Link to “Intent to Implement” blink-dev discussion

Proposal on net-dev: https://groups.google.com/a/chromium.org/forum/#!searchin/net-dev/proxy$20resolver/net-dev/73f9B5vFphI/sUHEsnxBd7oJ

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Supported on all desktop platforms (win/mac/linux/chromeos).

Demo link

Go to chrome://flags and enable the "Enable Out-of-process V8 Proxy Resolver" flag, or pass --v8-pac-mojo-out-of-process on the command line.

Compatibility Risk

None expected. This is a UA feature and not exposed to web developers. For users, this is an implementation change with no change to behaviour.

[Chris Bentzel]

SGTM

Can you summarize the performance and success rate impact?

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAATStaPJUAz8HWGiSOQ-4%3D8FTOWsURH7RbFpe3aCE-XQ04g8Zg%40mail.gmail.com.

[Chris Bentzel]

Oh, and thanks for moving this along. This has been a long requested infrastructural change. It sounds like it also uncovered a number of details about using Mojo in Chromium code.

[Anand K. Mistry]

Firstly, this was running in dev/canary for a while, but I let the trial expire (D'oh!). So, I'm posting numbers for 1st Dec (M48 dev). I'm starting the trial up again and should have numbers for M50 in a few days.

Crash rate is similar to the current behaviour within one stddev. This is expected. I don't think V8 is a significant cause of crashers in the browser process. Looking at crash reports suggests that ~0.1% of V8 crashes are in the browser process. A new source of crashes would be Mojo itself, but M48 has a number of fixes to the core, so this shouldn't be a significant source of crashes. But I'm continuously monitoring Mojo crash reports for on-going work in the Mojo core.

Usage of proxy scripts appears to be low, as expected. ~5% of URLs are resolved using a proxy script. Out of URLs that are resolved using the proxy script, the 90% percentile goes from 3.79ms to 16.5ms. This is a significant jump, but keep in mind that moving to out-of-process introduces IPC latency, as well as process scheduling effects from the OS. Also, M48 has a significant scaling issue with Mojo that's resolved in M50 (and this intent-to-ship is driven by this fix). I'll update this thread again once I have M50 numbers. Looks like we don't have error rates for resolve job. I'll add that.

If we look at total time for a HTTP job, the curve is identical, with the 95% percentile before being 4941ms and after being 4992ms. The 95% percentile page load time goes from 31.1s to 31.4s.

Finally, memory. Looking at my own browser, the proxy resolver is using ~15M of memory, of which ~7M is the JS heap (and 0 in the browser). Of course, if you don't use a proxy script (most users), then the proxy resolver process doesn't run.