Почему одновременный сборщик мусора иногда вызывает ExecutionEngineException (для MSDN)? - PullRequest
Новая
       41

Почему одновременный сборщик мусора иногда вызывает ExecutionEngineException (для MSDN)?

12 голосов
/ 23 сентября 2011

Согласно MSDN , есть «совет» о том, что приложение .NET, работающее под большой нагрузкой с одновременной сборкой мусора (либо <gcConcurrent enabled="true"/>, либо не указано, так как это поведение по умолчанию), может выдатьExecutionEngineException.Кто-нибудь знает статью Microsoft KB или другой источник, который предоставляет дополнительную информацию по этому вопросу?

Мы испытали это непосредственно с приложением-службой Windows на базе NHibernate 3.2, которое неизменно падало через самое большее несколько часовоперация.Мы смогли отследить исключение для вызова ISession.Flush ().

На nhusers есть поток , сообщающий о том, что, похоже, возникает та же проблема.Его предложенный обходной путь, который должен был отключить параллельный GC, до сих пор работал для нас, хотя переключение на GC в режиме сервера (<gcServer enable="true"/>), которое неявно отключает параллельный GC, также помогло.

Прежде чем отправлять это в MS как ошибку, я хотел бы узнать, есть ли у кого-нибудь дополнительная информация о сопутствующей нестабильности GC, о которой упоминается совет.

1 Ответ

5 голосов
/ 24 сентября 2011

Я подозреваю, что это происходит, когда приложение находится под большой нагрузкой, потому что, когда включен одновременный сборщик мусора, сборщик мусора пытается выполнить свою работу без приостановки вашего приложения. Если GC сталкивается с ситуацией, когда он пытается переместить память во время фазы сжатия цикла GC и не может переместить память или не может правильно обновить указатели приложений, это может привести к тому, что среда выполнения выбросит это исключение, так как это приведет к переводу вашего приложения в потенциально недопустимое состояние.

Как отметил @casperOne в своем комментарии, это исключение помечено как устаревшее в .NET 4.0, хотя это не обязательно означает, что GC по-прежнему не может войти в то же состояние, из-за которого оно выдало исключение. NET 3.5. Если GC действительно оказался в том же состоянии, среда выполнения выдаст команду FailFast и завершит работу, а не вызовет исключение.

...