We noticed some oddities in the UMA data for GPU.GPUProcessLifetimeEvents, GPU.SwiftShaderLifetimeEvents, GPU.DisplayCompositorLifetimeEvents during the OOP-D finch trial.

https://uma.googleplex.com/p/chrome/variations/?sid=e68a5511c891c0f3139ea7287ef0ee0b

I've taken a look at the code and roughly understand how it works. On GPU process launch, for any reason, GPU.GPUProcessLifetimeEvents.LAUNCHED is incremented. If the GPU process, which is running GPU compositing crashes GPU.GPUProcessLifetimeEvents.DIED_FIRST_TIME is supposed to be incremented. However, the order is reversed and count is incremented then UMA recorded so GPU.GPUProcessLifetimeEvents.DIED_SECOND_TIME is increment instead of DIED_FIRST_TIME. This is a bug.

The GPU process can crash three times (recently, I'll come back to this) before we give up on GPU compositing and switch to software compositing with SwiftShader GL. So after three crashes we'd have the following histograms:

GPU.GPUProcessLifetimeEvents.LAUNCHED = 4
GPU.GPUProcessLifetimeEvents.DIED_SECOND_TIME = 1
GPU.GPUProcessLifetimeEvents.DIED_THIRD_TIME = 1
GPU.GPUProcessLifetimeEvents.DIED_FOURTH_TIME = 1

The fourth launch of the GPU process is (likely) only going to be for SwiftShader GL with software compositing. There is a different UMA histogram GPU.SwiftShaderLifetimeEvents.LAUNCHED that probably should have been incremented instead of GPU.GPUProcessLifetimeEvents.LAUNCHED.  If another GPU process crash happens now then GPU.SwiftShaderLifetimeEvents.DIED_FIRST_TIME is incremented (which is correct). We'd have the following histograms now after four crashes:

GPU.GPUProcessLifetimeEvents.LAUNCHED = 5
GPU.GPUProcessLifetimeEvents.DIED_SECOND_TIME = 1
GPU.GPUProcessLifetimeEvents.DIED_THIRD_TIME = 1
GPU.GPUProcessLifetimeEvents.DIED_FOURTH_TIME = 1
GPU.SwiftShaderLifetimeEvents.DIED_FIRST_TIME = 1

There is a similar fallback behaviour with SwiftShader GL where GPU process can crash 3 times before we give up on it and just use software compositing with WebGL disabled. For non-OOP-D we wouldn't start the GPU process again at this point. After six GPU process crashes have the following histograms:

GPU.GPUProcessLifetimeEvents.LAUNCHED = 6
GPU.GPUProcessLifetimeEvents.DIED_SECOND_TIME = 1
GPU.GPUProcessLifetimeEvents.DIED_THIRD_TIME = 1
GPU.GPUProcessLifetimeEvents.DIED_FOURTH_TIME = 1
GPU.SwiftShaderLifetimeEvents.DIED_FIRST_TIME = 1
GPU.SwiftShaderLifetimeEvents.DIED_SECOND_TIME = 1
GPU.SwiftShaderLifetimeEvents.DIED_THIRD_TIME = 1

What I think the histograms should look at this point is this instead are as follows:

GPU.GPUProcessLifetimeEvents.LAUNCHED = 3
GPU.GPUProcessLifetimeEvents.DIED_FIRST_TIME = 1
GPU.GPUProcessLifetimeEvents.DIED_SECOND_TIME = 1
GPU.GPUProcessLifetimeEvents.DIED_THIRD_TIME = 1
GPU.SwiftShaderLifetimeEvents.LAUNCHED = 3
GPU.SwiftShaderLifetimeEvents.DIED_FIRST_TIME = 1
GPU.SwiftShaderLifetimeEvents.DIED_SECOND_TIME = 1
GPU.SwiftShaderLifetimeEvents.DIED_THIRD_TIME = 1

Another thing to note is that we forgive one crash per hour when deciding if falling back to software compositing is necessary. So GPU.GPUProcessLifetimeEvents.5, GPU.GPUProcessLifetimeEvents.6, etc. can also get incremented since we record the actual crash count not the recent crash count.

Another thing to note is that with OOP-D the GPU process is still launched for pure software compositing. There is another UMA histogram category added GPU.DisplayCompositorLifetimeEvents. It works similar to GPU.SwiftShaderLifetimeEvents where the LAUNCHED is attributed GPU.GPUProcessLifetimeEvents.LAUNCHED but the crash bucket is correct.

I can fix the bucketing if that sounds reasonable? It will be problematic for historical comparisons however.