I ran the system_health background stories. The memory usage of the processes:

process		PD		PSS
		in	out	in	out
Browser		17	15.5	56	47.5
Renderer	33	33	71	66
GPU		-	12	-	24

Total		51	60	127	138

On Killing Gpu process:
Total		51	48	127	126

PSS=126 because the shared memory of GPU process will mostly remain even if we kill GPU process. The apk and so mmap or even the textures backed by SharedMemory since renderer will keep them alive.
So, I am assuming that the PSS will reduce only by the private dirty of the GPU process which does not give us any win over having GPU process inside browser.

I can investigate the 3MB difference in private dirty. I know for sure that the ShaderTranslator is kept in memory even when going to background.

Yep, having an understanding of the 3MB difference would be good.

Alex, looks like after the GL context drop change, the background memory savings from killing GPU process are minimal, but the overhead of running a separate process is 9-11MB. My conclusion from this would be that we should keep it in-process for low-end devices given that our GPU crash rates are not too bad.

OK, thanks for the measurements.  I can accept the pure memory case for splitting the GPU process isn't there.

In practice, it seems that the WebGL being blacklisted when the GPU process is not split is the most noticeable consequence of this: see  http://crbug.com/730306 .  For 512MB devices it's a niche consideration, but if starting in Android O we're going to blacklist WebGL for all 1GB devices (the most popular category of devices), and I expect that will be noticed and complained about more widely, and possibly drive away developers from WebGL.

What's the reason that WebGL has to be blacklisted when GPU runs in-proc and not blacklisted for out-of-proc?

Superficially, WebGL should work fine in-process, as it does in Android WebView for example.  But there's a stability reason: WebGL can do crazy stuff to hang the GPU driver and we want to kill and restart the GPU process instead of browser process.

Originally WebGL was whitelisted based on presence of the GL "robustness" extension, but this was uncommon and didn't work well even when it was claimed supported, so we switched to GPU process restart as our only recovery mechanism, leaving non-GPU-process devices blacklisted.

I think there's security reasons as well but the original reason for the policy was stability.

I'm pretty sure the reason for blacklisting WebGL with the in-process GPU on Android was simply that the KHR_robustness extension wasn't behaving very well across a range of devices, rather than because of security issues.