¿Por qué el GC simultáneo a veces causa ExecutionEngineException (por MSDN)?

Question

De acuerdo con MSDN, hay una "sugerencia" que indica que una aplicación .NET que se ejecuta bajo carga pesada con recolección de basura concurrente (<gcConcurrent enabled="true"/> o no especificada, ya que es el comportamiento predeterminado) puede lanzar ExecutionEngineException. ¿Alguien conoce un artículo de Microsoft KB u otra fuente que proporcione antecedentes adicionales sobre esto?

Hemos experimentado esto directamente con una aplicación de servicio de Windows basada en NHibernate 3.2, que se bloqueará invariablemente después de unas pocas horas de funcionamiento. Pudimos rastrear la excepción a la llamada ISession.Flush().

Hay un thread en personas que informan lo que parece ser el mismo problema. Su solución sugerida, que era deshabilitar el GC concurrente, nos ha funcionado hasta ahora, aunque cambiar al modo de servidor GC (<gcServer enable="true"/>), que implícitamente deshabilita GC concurrente, también lo hizo.

Antes de enviar esto a MS como un error, me gustaría averiguar si alguien tiene información adicional sobre la inestabilidad concurrente de GC que menciona la sugerencia.

Answer 1

Sospecho que esto ocurre cuando la aplicación está bajo mucha carga porque cuando el GC concurrente está habilitado, el GC intenta hacer su trabajo sin detener su aplicación. Si el GC encuentra una situación en la que intenta mover la memoria durante la fase de compactación de un ciclo de GC y no puede mover la memoria o no puede actualizar correctamente los punteros de la aplicación, eso podría provocar que el tiempo de ejecución arroje este excepción ya que terminaría poniendo su aplicación en un estado potencialmente inválido.

Como @casperOne señaló en su comentario, esta excepción está marcada como obsoleta en .NET 4.0, aunque eso no significa necesariamente que el GC aún no pueda ponerse en el mismo estado que provocó que lanzara la excepción en .NET 3.5. Si el GC se colocó en ese mismo estado, el tiempo de ejecución emitirá un comando FailFast y terminará en lugar de lanzar una excepción.