Perché il GC simultaneo causa talvolta ExecutionEngineException (per MSDN)?

Question

In base a MSDN, esiste un "suggerimento" che indica che un'applicazione .NET in esecuzione con carico pesante con garbage collection simultanea (o <gcConcurrent enabled="true"/> o non specificata, poiché è il comportamento predefinito) può lanciare un'eccezioneExecutionEngineException. Qualcuno è a conoscenza di un articolo di Microsoft KB o di un'altra fonte che fornisce ulteriori informazioni su questo?

Abbiamo sperimentato questo direttamente con un'applicazione di servizio Windows basata su NHibernate 3.2, che invariabilmente si interromperà dopo al massimo poche ore di funzionamento. Siamo stati in grado di rintracciare l'eccezione alla chiamata ISession.Flush().

C'è un thread su nhuzi che riportano quello che sembra essere lo stesso problema. La sua soluzione suggerita, che era quella di disabilitare il GC simultaneo, ha funzionato fino ad ora per noi, anche se il passaggio a GC in modalità server (<gcServer enable="true"/>), che disabilita implicitamente il GC simultaneo, ha fatto anche il trucco.

Prima di inviare questo a MS come un bug, vorrei scoprire se qualcuno là fuori ha ulteriori informazioni sulla instabilità concomitante di GC che il suggerimento menziona.

Answer 1

Sospetto che ciò si verifichi quando l'applicazione è sottoposta a un carico elevato poiché quando GC concorrente è abilitato, il GC tenta di eseguire il proprio lavoro senza sospendere l'applicazione. Se il GC incontra una situazione in cui tenta di spostare la memoria durante la fase di compattazione di un ciclo di GC e non è in grado di spostare la memoria o non è in grado di aggiornare correttamente i puntatori dell'applicazione, ciò potrebbe causare il runtime a lanciare questo eccezione dato che finirebbe per mettere la tua applicazione in uno stato potenzialmente invalido.

Come ha sottolineato @casperOne nel suo commento, questa eccezione è contrassegnata come obsoleta in .NET 4.0 sebbene ciò non significhi necessariamente che il GC non riesca ancora a ottenere se stesso nello stesso stato in cui è stato generato l'eccezione .NET 3.5. Se il GC si è trovato nello stesso stato, il runtime invierà un comando FailFast e terminerà invece di generare un'eccezione.