If we lose a context, GpuCommandBufferStub::CheckContextLost has logic to possibly exit the GPU process:

https://cs.chromium.org/chromium/src/gpu/ipc/service/gpu_command_buffer_stub.cc?q=CheckContextLost&sq=package:chromium&l=1236

bool was_lost_by_robustness =
    decoder_ && decoder_->WasContextLostByRobustnessExtension();

// Work around issues with recovery by allowing a new GPU process to launch.
if ((was_lost_by_robustness ||
     context_group_->feature_info()->workarounds().exit_on_context_lost)) {
  channel_->gpu_channel_manager()->MaybeExitOnContextLost();
}


The exit_on_context_lost workaround is set on all windows devices, which means that we'll exit the GPU process even if the underlying context is *not* lost. I don't think that ever was the intent.

The logic initially was added by https://chromiumcodereview.appspot.com/12617020 which explicitly means to handle D3D9 device lost. I believe at the time the only cause of context loss was pretty much that.

At some point we added other means of losing context (some logic errors, oom-loses-context, etc.). And this was compensated by some other logic (e.g. https://codereview.chromium.org/1282973004 ) but I don't think we ended up at the right place.

Other relevant bugs:
https://bugs.chromium.org/p/chromium/issues/detail?id=475676
https://bugs.chromium.org/p/chromium/issues/detail?id=480545


So, I think we should revisit this. In particular, I don't think we should ever terminate the GPU process for something that happens in Chrome code (as opposed to bad driver state). See e.g.  crbug.com/773199 

This will be doubly important with Viz which keeps even more state.