Coleta de lixo na API de criação de perfil
Geradores de perfis podem receber notificações de coleta de lixo.
Quando o usuário Especifica o sinalizador COR_PRF_MONITOR_GC, todos os eventos de coleta de lixo, exceto para ICorProfilerCallback::ObjectAllocated eventos serão gerados no profiler. ObjectAllocatedeventos explicitamente são controlados pelo sinalizador COR_PRF_MONITOR_OBJECT_ALLOCATED por motivos de desempenho. Observe que quando o sinalizador COR_PRF_MONITOR_GC está habilitado, coleta de lixo simultâneos está desativada.
No.NET Framework versão 1.0 e 1.1, o criador de perfil de código determina que coleta de lixo está ocorrendo monitorando o ICorProfilerCallback::RuntimeSuspendFinished e ICorProfilerCallback::RuntimeResumeStarted retornos de chamada quando o motivo de suspensão é COR_PRF_SUSPEND_FOR_GC. Durante o desligamento, o common language runtime (CLR) também fica suspensa e uma ou mais coleções de lixo podem ocorrer sem que o criador de perfil de código que está sendo notificado, porque o runtime já está em um estado suspenso. Detectando a conclusão da coleta de lixo nessas circunstâncias não é trivial. O criador de perfil de código possui que detectar o primeiro ObjectAllocated retorno de chamada que levou colocar após um ICorProfilerCallback::ObjectReferences ou ICorProfilerCallback::RootReferences retorno de chamada.
No.NET Framework versão 2.0 e posteriores, o criador de perfil de código pode usar o ICorProfilerCallback2::GarbageCollectionStarted e ICorProfilerCallback2::GarbageCollectionFinished retornos de chamada para determinar que coleta de lixo está ocorrendo e identificar quais gerações são abordadas. (Para obter mais informações sobre as gerações de coleta de lixo, consulte o COR_PRF_GC_GENERATION enumeração.) Esses retornos de chamada não tem o problema de desligamento, mencionado na seção anterior.
Observação
Não há suporte para a coleta de lixo simultâneas em aplicativos em execução no WOW64 x 86 emulador em sistemas de 64 bits que implementam a arquitetura Intel Itanium (anteriormente chamado de IA-64).Para obter mais informações sobre como usar o WOW64 em sistemas de 64 bits do Windows, consulte aplicativos executando 32 bits.
O bloqueio de coleta de lixo
Quando o common language runtime chama determinados métodos de ICorProfilerCallback interface, o tempo de execução não é possível executar uma coleta de lixo até que o profiler retorna o controle de chamada. Isso ocorre porque os serviços de perfil sempre não é possível construir a pilha em um estado que é seguro para a coleta de lixo. Em vez disso, a coleta de lixo está desabilitada em torno desse retorno de chamada. Nesses casos, o profiler deve retornar o controle mais rápido possível. Essa situação se aplica para os retornos de chamada a seguintes:
ICorProfilerCallback::ExceptionOSHandlerEnter, ICorProfilerCallback::ExceptionOSHandlerLeave
ICorProfilerCallback::ExceptionUnwindFunctionEnter, ICorProfilerCallback::ExceptionUnwindFunctionLeave
ICorProfilerCallback::ExceptionUnwindFinallyEnter, ICorProfilerCallback::ExceptionUnwindFinallyLeave
ICorProfilerCallback::ExceptionCatcherEnter, ICorProfilerCallback::ExceptionCatcherLeave
ICorProfilerCallback::ExceptionCLRCatcherFound, ICorProfilerCallback::ExceptionCLRCatcherExecute
ICorProfilerCallback::COMClassicVTableCreated, ICorProfilerCallback::COMClassicVTableDestroyed
Além disso, os retornos de chamada a seguintes permitem que o profiler para coleta de lixo do bloco, chamada a chamada, usando o fIsSafeToBlock parâmetro:
Observe que, se o profiler bloquear, ele será atrasar coleta de lixo. Esse atraso é inofensivo, contanto que o profiler não chama uma função CLR que dispara uma coleta de lixo ou aloca espaço no heap gerenciado.